Ước tính các yêu cầu IO cho việc sử dụng Bursty

Chúng tôi có một ứng dụng truy vấn cơ sở dữ liệu SQL định kỳ trong suốt cả ngày. Có những khoảng thời gian bằng 0 hoặc chỉ hoạt động nhẹ, xen kẽ với các yêu cầu riêng lẻ cho lượng dữ liệu tương đối lớn. Khi những yêu cầu đó đến, mục tiêu chính là cung cấp dữ liệu nhanh chóng và mục tiêu thứ yếu là thực hiện chi phí đó một cách hiệu quả. Do tính chất của ứng dụng, khá khó có khả năng dữ liệu / chỉ mục sẽ được lưu trong bộ nhớ cache từ truy vấn trước đó (người dùng khác nhau, làm việc trên các phần khác nhau của dữ liệu).

Đối với một hệ thống trải nghiệm sử dụng tương đối ổn định, tôi đã nghe quy tắc ngón tay cái để quan sát chiều dài hàng đợi đĩa và giữ số đó tương đối nhỏ. Điều này sẽ đặc biệt chạy trong AWS, nơi tôi đã thấy quy tắc ngón tay cái rằng độ dài hàng đợi đĩa là 1 trên 100 IOPS là hợp lý.

Làm thế nào tôi có thể ước tính các yêu cầu IO cho một hệ thống như vậy? Độ dài hàng đợi đĩa có phải là một chỉ báo đáng tin cậy khi xử lý các truy vấn riêng lẻ không? Có những số liệu khác mà tôi nên xem xét?

Số liệu chính tôi luôn xem xét cho IO trong SQL Server không phải là IOP hoặc Độ dài hàng đợi đĩa, mà là thông lượng đĩa (sec / đọc và sec / write). Nhìn chung, cơ sở dữ liệu không nói về số lượng thao tác bạn có thể ném vào đĩa, nhưng tốc độ các hoạt động đó được hoàn thành nhanh như thế nào. Nguyên tắc chung là có ít hơn 20ms / thao tác (mặc dù thấp hơn luôn tốt hơn). Chi tiết hơn có thể được tìm thấy trong bài viết này .

Chiều dài hàng đợi đĩa là một chỉ số không có thật và không còn phù hợp. Vấn đề với nó là giá trị đo hàng đợi cho một ổ đĩa, nhưng hiện tại chúng ta đang sống trong thời đại của RAID, SAN và bộ lưu trữ phân tán khác, không có cách nào để dịch đúng giá trị này thành một số có ý nghĩa. Một khởi đầu tuyệt vời cho các số liệu hiệu suất là poster này từ Quest / Dell cung cấp cho bạn rất nhiều thứ và giải thích cho lý do tại sao hoặc tại sao chúng không quan trọng. Bạn không phải sử dụng tất cả chúng, nhưng chúng là một sự khởi đầu.

Để kiểm tra IO của bạn, bạn phải hiểu khối lượng công việc của mình ở mức cao nhất. Có bao nhiêu giao dịch và bao nhiêu được lưu trữ? Trừ khi bạn biết và đã đo lường những điều này, thật sự rất khó để đánh giá. Bạn có thể tạo tải công việc và sử dụng các công cụ như SQLIO để kiểm tra bộ nhớ của mình, nhưng bạn sẽ cần các mẫu tải công việc để xây dựng một thử nghiệm thích hợp.

Cuối cùng, một lưu ý về AWS: Theo hiểu biết của tôi, Amazon sẽ không đảm bảo hiệu suất IO trong AWS. Điều này chủ yếu là vì bộ lưu trữ là một tài nguyên được chia sẻ lớn và không thể đánh giá mô hình của bạn và hàng xóm của bạn trên một khu vực lưu trữ cụ thể (xem vấn đề Hàng xóm ồn ào ).

Đề nghị của tôi sẽ là phân bổ càng nhiều bộ nhớ càng tốt. SQL Server sẽ chỉ đẩy mọi thứ ra khỏi bộ nhớ nếu nó chịu áp lực và không gian trong vùng đệm (dựa trên LRU-K). Vì vậy, nếu nhóm bộ đệm của bạn có thể lưu trữ hầu hết cơ sở dữ liệu trong bộ nhớ, bạn có thể giảm thiểu một số hiệu suất bùng nổ. Ngoài ra, hãy xem xét các chiến thuật có thể giữ cho các đối tượng bộ đệm "ấm". Cuối cùng, hãy theo dõi SQL 2014 và tính năng Hekaton mới .