Lưu ý:Bài đăng này ban đầu chỉ được xuất bản trong sách điện tử của chúng tôi, Kỹ thuật hiệu suất cao cho SQL Server, Tập 4. Bạn có thể tìm hiểu về sách điện tử của chúng tôi tại đây.
Tôi thường xuyên nhận được câu hỏi, "Tôi phải bắt đầu từ đâu khi cố gắng điều chỉnh phiên bản SQL Server?" Câu trả lời đầu tiên của tôi là hỏi họ về cấu hình của phiên bản của họ. Nếu một số thứ nhất định không được định cấu hình đúng cách thì việc bắt đầu xem xét các truy vấn chạy lâu hoặc chi phí cao ngay lập tức có thể bị lãng phí công sức.
Tôi đã viết blog về những điều phổ biến mà quản trị viên bỏ lỡ nơi tôi chia sẻ nhiều cài đặt mà quản trị viên nên thay đổi từ cài đặt mặc định của SQL Server. Đối với các mục liên quan đến hiệu suất, tôi nói với họ rằng họ nên kiểm tra những điều sau:
- Cài đặt bộ nhớ
- Cập nhật số liệu thống kê
- Duy trì chỉ mục
- MAXDOP và ngưỡng chi phí cho tính song song
- các phương pháp hay nhất về tempdb
- Tối ưu hóa cho khối lượng công việc đột xuất
Khi tôi vượt qua các mục cấu hình, tôi hỏi họ đã xem số liệu thống kê về tệp và chờ cũng như các truy vấn chi phí cao chưa. Phần lớn thời gian câu trả lời là "không" - kèm theo lời giải thích rằng họ không chắc làm thế nào để tìm thấy thông tin đó.
Thông thường, tuân thủ phổ biến khi ai đó nói rằng họ cần điều chỉnh SQL Server là nó chạy chậm. Chậm có nghĩa là gì? Đó là một báo cáo nhất định, một ứng dụng cụ thể hay mọi thứ? Nó chỉ mới bắt đầu xảy ra hay đã trở nên tồi tệ hơn theo thời gian? Tôi bắt đầu bằng cách hỏi các câu hỏi thông thường về việc sử dụng bộ nhớ, CPU và ổ đĩa so với khi mọi thứ bình thường, sự cố mới bắt đầu xảy ra và điều gì đã thay đổi gần đây. Trừ khi khách hàng đang nắm bắt đường cơ sở, họ không có số liệu để so sánh để biết liệu thống kê hiện tại có bất thường hay không.
Gần như mọi SQL Server mà tôi làm việc đều lưu trữ nhiều hơn một cơ sở dữ liệu người dùng. Khi một khách hàng báo cáo rằng SQL Server đang chạy chậm, hầu hết thời gian họ lo lắng về một ứng dụng cụ thể đang gây ra sự cố cho khách hàng của họ. Phản ứng đầu gối là ngay lập tức tập trung vào cơ sở dữ liệu cụ thể đó, tuy nhiên, thường thì một quá trình khác có thể tiêu tốn tài nguyên quý giá và cơ sở dữ liệu của ứng dụng đang bị ảnh hưởng. Ví dụ:nếu bạn có một cơ sở dữ liệu báo cáo lớn và ai đó đã khởi động một báo cáo lớn làm bão hòa đĩa, tăng đột biến CPU và xóa bộ nhớ cache của kế hoạch, bạn có thể đặt cược rằng các cơ sở dữ liệu người dùng khác sẽ chậm lại trong khi báo cáo đó đang được tạo.
Tôi luôn muốn bắt đầu bằng cách xem số liệu thống kê của tệp. Đối với SQL Server 2005 trở lên, bạn có thể truy vấn sys.dm_io_virtual_file_stats DMV để nhận thống kê I / O cho từng dữ liệu và tệp nhật ký. DMV này đã thay thế hàm fn_virtualfilestats. Để nắm bắt số liệu thống kê về tệp, tôi muốn sử dụng một tập lệnh mà Paul Randal đã tổng hợp lại:ghi lại độ trễ IO trong một khoảng thời gian. Tập lệnh này sẽ ghi lại đường cơ sở và 30 phút sau (trừ khi bạn thay đổi thời lượng trong phần CHỜ TRÌ HOÃN), nắm bắt các số liệu thống kê và tính toán các đồng bằng giữa chúng. Tập lệnh của Paul cũng thực hiện một chút phép toán để xác định độ trễ đọc và ghi, điều này giúp chúng ta đọc và hiểu dễ dàng hơn nhiều.
Trên máy tính xách tay của mình, tôi đã khôi phục một bản sao của cơ sở dữ liệu AdventureWorks2014 vào ổ USB để tôi có tốc độ đĩa chậm hơn; Sau đó, tôi bắt đầu một quá trình để tạo ra một tải chống lại nó. Bạn có thể xem kết quả bên dưới trong đó độ trễ ghi cho tệp dữ liệu của tôi là 240 mili giây và độ trễ ghi cho tệp nhật ký của tôi là 46 mili giây. Độ trễ cao đến mức này thật là rắc rối.
Bất cứ điều gì trên 20ms đều bị coi là xấu, như tôi đã chia sẻ trong một bài viết trước:theo dõi độ trễ đọc / ghi. Độ trễ đọc của tôi là ổn, nhưng cơ sở dữ liệu AdventureWorks2014 đang bị chậm ghi. Trong trường hợp này, tôi sẽ điều tra những gì đang tạo ra các bản ghi cũng như điều tra hiệu suất hệ thống con I / O của tôi. Nếu đây là độ trễ đọc quá cao, tôi sẽ bắt đầu điều tra hiệu suất truy vấn (tại sao nó thực hiện nhiều lần đọc như vậy, chẳng hạn như từ các chỉ mục bị thiếu), cũng như hiệu suất tổng thể của hệ thống con I / O.
Điều quan trọng là phải biết hiệu suất tổng thể của hệ thống con I / O của bạn và cách tốt nhất để biết nó có khả năng gì là đo điểm chuẩn. Glenn Berry nói về điều này trong bài viết phân tích hiệu suất I / O cho SQL Server. Glenn giải thích về độ trễ, IOPS, thông lượng và cho thấy CrystalDiskMark là một công cụ miễn phí mà bạn có thể sử dụng để tạo cơ sở cho bộ nhớ của mình.
Sau khi tìm hiểu xem các thống kê tệp đang hoạt động như thế nào, tôi muốn xem số liệu thống kê chờ bằng cách sử dụng DMV sys.dm_os_wait_stats, trả về thông tin về tất cả các lần đợi đã xảy ra. Đối với điều này, tôi chuyển sang một kịch bản khác mà Paul Randal cung cấp trong số liệu thống kê chờ đợi của anh ấy trong một khoảng thời gian đăng trên blog. Tập lệnh của Paul lại giải một bài toán nhỏ cho chúng ta nhưng quan trọng hơn, nó loại trừ rất nhiều sự chờ đợi lành tính mà chúng ta thường không quan tâm. Tập lệnh này cũng có TRÌ HOÃN CHỜ và được đặt thành 30 phút. Đọc số liệu thống kê về thời gian chờ có thể phức tạp hơn một chút:Bạn có thể có số lần chờ có vẻ cao dựa trên tỷ lệ phần trăm, nhưng thời gian chờ trung bình quá thấp nên không có gì phải lo lắng.
Tôi đã bắt đầu quá trình tải tương tự và ghi lại số liệu thống kê chờ của mình, mà tôi đã hiển thị bên dưới. Để biết lời giải thích cho nhiều kiểu chờ đợi này, bạn có thể đọc một bài đăng khác trên blog của Paul, thống kê thời gian chờ hoặc vui lòng cho tôi biết cảm giác đau ở đâu, cùng với một số bài đăng của anh ấy trên blog này.
Trong đầu ra có nội dung này, sự chờ đợi của PAGEIOLATCH có thể chỉ ra một nút cổ chai với hệ thống con I / O của tôi, nhưng cũng có thể là sự cố bộ nhớ, thay vào đó là tìm kiếm quét bảng hoặc một loạt các sự cố khác. Trong trường hợp của tôi, chúng tôi biết đó là sự cố đĩa vì tôi đang lưu trữ cơ sở dữ liệu trên thẻ USB. Thời gian chờ LCK_M_S rất cao, tuy nhiên chỉ có một trường hợp chờ đợi. WRITELOG của tôi cũng cao hơn những gì tôi muốn, nhưng có thể hiểu được các vấn đề về độ trễ với thanh USB. Điều này cũng cho thấy CXPACKET đang đợi và sẽ dễ xảy ra phản ứng giật đầu gối và nghĩ rằng bạn có vấn đề về song song / MAXDOP, tuy nhiên bộ đếm AvgWait_S rất thấp. Hãy cẩn thận khi sử dụng chờ khắc phục sự cố. Hãy để nó là một hướng dẫn cho bạn biết những điều không phải là vấn đề cũng như cho bạn định hướng về nơi để tìm kiếm các vấn đề. Khắc phục sự cố thích hợp là tương quan các hành vi từ nhiều lĩnh vực để thu hẹp vấn đề.
Sau khi xem tệp và chờ thống kê, tôi bắt đầu tìm hiểu các truy vấn chi phí cao dựa trên các vấn đề tôi đã tìm thấy. Đối với điều này, tôi chuyển sang Truy vấn Thông tin Chẩn đoán của Glenn Berry. Các tập hợp truy vấn này là tập lệnh truy cập mà nhiều nhà tư vấn sử dụng. Glenn và cộng đồng liên tục cung cấp các bản cập nhật để làm cho chúng có nhiều thông tin và mạnh mẽ nhất có thể. Một trong những truy vấn yêu thích của tôi là các truy vấn được lưu trong bộ nhớ cache hàng đầu theo số lượng thực thi. Tôi thích tìm các truy vấn hoặc thủ tục được lưu trữ có số lượng thực thi cao cùng với tổng số lượng_tính_tạo_tạo_lực_tạo_triển cao. Nếu những truy vấn đó có cơ hội điều chỉnh thì bạn có thể nhanh chóng tạo ra sự khác biệt lớn cho máy chủ. Cũng được bao gồm trong các tập lệnh là các SP được lưu trong bộ nhớ cache hàng đầu theo tổng số lần đọc logic và các SP được lưu trong bộ nhớ cache hàng đầu theo tổng số lần đọc vật lý. Cả hai điều này đều tốt cho việc tìm kiếm các lần đọc cao với số lượng thực thi cao để bạn có thể giảm số lượng I / Os.
Ngoài các tập lệnh của Glenn, tôi muốn sử dụng sp_whoisactive của Adam Machanic để xem những gì hiện đang chạy.
Có rất nhiều thứ để điều chỉnh hiệu suất hơn là chỉ xem tệp và số liệu thống kê chờ và các truy vấn chi phí cao, tuy nhiên đó là nơi tôi muốn bắt đầu. Đó là một cách nhanh chóng phân tích môi trường để bắt đầu xác định nguyên nhân gây ra sự cố. Không có bằng chứng hoàn toàn ngu ngốc để điều chỉnh:những gì mọi DBA sản xuất cần là một danh sách kiểm tra những thứ cần chạy qua để loại bỏ và một bộ sưu tập các tập lệnh thực sự tốt để chạy qua để phân tích tình trạng của hệ thống. Có một đường cơ sở là chìa khóa để nhanh chóng loại trừ hành vi bình thường và bất thường. Người bạn tốt của tôi, Erin Stellato, có toàn bộ khóa học về Pluralsight có tên là SQL Server:Benchmarking và Baselining nếu bạn cần trợ giúp về việc thiết lập và nắm bắt đường cơ sở của mình.
Tốt hơn, hãy sở hữu một công cụ hiện đại như SQL Sentry Performance Advisor sẽ không chỉ thu thập và lưu trữ thông tin lịch sử để lập hồ sơ và xu hướng, đồng thời giúp dễ dàng truy cập vào tất cả các chi tiết được đề cập ở trên và hơn thế nữa, mà còn cung cấp khả năng so sánh hoạt động với các đường cơ sở được tích hợp sẵn hoặc do người dùng xác định, duy trì hiệu quả các chỉ mục mà không cần nhấc ngón tay lên và cảnh báo hoặc tự động hóa các phản hồi dựa trên kiến trúc điều kiện tùy chỉnh rất mạnh mẽ. Ảnh chụp màn hình sau đây mô tả chế độ xem lịch sử của bảng điều khiển Trình tư vấn hiệu suất, với đĩa chờ màu cam, cơ sở dữ liệu I / O ở dưới cùng bên phải và các đường cơ sở so sánh giai đoạn hiện tại và trước đó trên mọi biểu đồ (nhấp để phóng to):
Các công cụ giám sát chất lượng không miễn phí, nhưng chúng cung cấp rất nhiều chức năng và hỗ trợ cho phép bạn tập trung vào các vấn đề hiệu suất trên máy chủ của mình, thay vì tập trung vào các truy vấn, công việc và cảnh báo có thể cho phép bạn tập trung vào các vấn đề về hiệu suất của mình - nhưng chỉ khi bạn làm đúng. Việc không phát minh lại bánh xe thường có giá trị lớn.
