Một trong những điều tuyệt vời và kinh khủng của Internet là, một khi thứ gì đó được đăng trên ether, về cơ bản nó sẽ không bao giờ biến mất. (Một ngày nào đó, các chính trị gia sẽ nhận ra điều này. Thực tế chúng ta có thể dễ dàng kiểm tra tính nhất quán của chúng.) Do nội dung được đăng lên Internet có tuổi thọ cao, rất nhiều chủ đề điều chỉnh hiệu suất trở thành "thây ma". Chúng tôi bắn chết chúng, nhưng chúng vẫn quay trở lại!
Nói cách khác, các đề xuất cũ đó là một phương pháp hay nhất được đề xuất từ lâu, cho một phiên bản SQL Server cụ thể, nhưng hiện không thích hợp cho phiên bản mới hơn. Không có gì lạ đối với tôi, khi phát biểu tại một hội nghị, gặp phải một người vẫn bám vào các cài đặt và kỹ thuật chưa được thực hành tốt kể từ những ngày của SQL Server 2000. Hướng dẫn Thao tác SQL Server 2000 về Dung lượng / Bộ nhớ chứa nhiều " phương pháp hay nhất "đề xuất rất cụ thể cho từng phiên bản và ngày nay không còn áp dụng nữa.
Vì vậy, đây là một ví dụ. % Disk Time và Disk Queue Length Bộ đếm PerfMon được đề xuất nhiều như là chỉ báo hiệu suất chính cho hiệu suất I / O. SQL Server ném rất nhiều I / O vào các đĩa bằng cách sử dụng scatter / collect để tối đa hóa việc sử dụng hệ thống con I / O dựa trên đĩa. Cách tiếp cận này dẫn đến sự bùng nổ ngắn của độ sâu hàng đợi dài trong các điểm kiểm tra và đọc trước cho một phiên bản của SQL Server. Đôi khi khối lượng công việc của máy chủ đến mức đĩa của bạn không thể theo kịp I / O được đẩy vào đó và khi điều đó xảy ra, bạn cũng sẽ thấy độ dài hàng đợi dài. Kịch bản bùng nổ ngắn không phải là một vấn đề. Kịch bản kéo dài độ dài hàng đợi thường là một vấn đề. Vậy đó có phải là một thực hành tốt không?
Nói một cách ngắn gọn, không quá nhiều.
Những bộ đếm đó vẫn có thể được sử dụng trên một phiên bản của SQL Server chỉ có một đĩa cứng (mặc dù điều đó cực kỳ hiếm ngày nay). Tại sao?
Bộ đếm PerfMon % Disk Time là một chỉ số hiệu suất không có thật vì một số lý do. Nó không tính đến các yêu cầu I / O không đồng bộ. Nó không thể cho biết cấu hình hiệu suất thực sự của một bộ RAID bên dưới có thể là gì, vì chúng chứa nhiều ổ đĩa. Bộ đếm PerfMon Disk Queue Length cũng hầu như vô dụng, ngoại trừ trên Máy chủ SQL với một đĩa vật lý duy nhất, bởi vì bộ đệm điều khiển đĩa cứng làm xáo trộn có bao nhiêu hoạt động I / O thực sự đang chờ xử lý trên hàng đợi hay không. Trên thực tế, một số đĩa cứng thậm chí còn có bộ nhớ đệm ghi rất nhỏ, điều này càng làm rối ren về việc liệu I / O có thực sự được xếp hàng đợi hay không, trong bộ nhớ đệm ở đâu đó giữa hệ điều hành và đĩa, hay cuối cùng đã hoàn thành. vào CMOS trên đĩa.
Bộ đếm PerfMon tốt hơn
Thay vì sử dụng các bộ đếm PerfMon đó, hãy sử dụng Avg Disk Reads/sec , Avg Disk Writes/sec và Avg Disk Transfers/sec để theo dõi hiệu suất của hệ thống con đĩa. Các bộ đếm này theo dõi số lượng I / Os trung bình đọc, I / Os ghi và kết hợp I / Os đọc và ghi xảy ra trong giây cuối cùng. Đôi khi, tôi muốn theo dõi các chỉ số giống nhau theo khối lượng dữ liệu hơn là tỷ lệ hoạt động I / O. Vì vậy, để có được dữ liệu đó, bạn có thể muốn dùng thử các bộ đếm PerfMon theo khối lượng cụ thể này:Avg Disk Transfer Bytes/sec , Avg Disk Read Bytes/sec và Avg Disk Write Bytes/sec .
Đối với Hiệu suất I / O của Máy chủ SQL, Sử dụng Chế độ xem Quản lý Động (DMV)
Và trừ khi bạn đang sống trong hang, bạn nên đảm bảo sử dụng Chế độ xem quản lý động (DMV) của SQL Server để kiểm tra hiệu suất I / O cho các phiên bản SQL Server gần đây. Một số DMV yêu thích của tôi cho I / O bao gồm:
- sys.dm_os_wait_stats
- sys.dm_os_waiting_tasks
- sys.dm_os_performance_counters
- sys.dm_io_virtual_file_stats
- sys.dm_io_pend_io_requests
- sys.dm_db_index_operational_stats
- sys.dm_db_index_usage_stats
Vậy bạn đang theo dõi các chỉ số hiệu suất I / O như thế nào? Bạn đang sử dụng cái nào?
Tôi rất mong nhận được phản hồi từ bạn!
Hãy tận hưởng,
-Kev
–Theo dõi tôi trên Twitter!
