Tác động của sự kiện mở rộng query_post_execution_showplan trong SQL Server 2012

Một trong những thách thức khó khăn nhất trong SQL Server là khắc phục sự cố với độ nhạy tham số hoặc ước tính bản số gây suy giảm hiệu suất của khối lượng công việc. Nói chung, bạn sẽ cần có kế hoạch thực thi thực tế từ câu lệnh đang chạy để có thể xác định nguyên nhân của việc giảm hiệu suất. Trong SQL Server 2012, Sự kiện mở rộng query_post_execution_showplan cung cấp khả năng nắm bắt kế hoạch thực thi thực tế cho các câu lệnh. Tuy nhiên, có vẻ như hữu ích, sự kiện này không phải là thứ có thể được sử dụng mà không ảnh hưởng đến hiệu suất đáng kể đối với khối lượng công việc đang chạy trên máy chủ.

Trong bài viết của tôi Đo lường “Chi phí quan sát” của SQL Trace so với Sự kiện mở rộng, tôi đã trình bày so sánh tác động hiệu suất của SQL Trace với một cấu hình giống hệt nhau bằng cách sử dụng Sự kiện mở rộng trong SQL Server 2012. Tại thời điểm đầu tiên tôi thực hiện thử nghiệm cho bài viết đó Tôi cũng đã thực hiện rất nhiều thử nghiệm sự kiện query_post_execution_showplan trong SQL Server 2012. Sự kiện này lần đầu tiên được giới thiệu trong SQL Server 2012 CTP1 khi nhiều sự kiện theo dõi được chuyển sang Sự kiện mở rộng để cung cấp tính ngang bằng với SQL Trace. Tại thời điểm đó, sự kiện chỉ có một tập hợp con của các cột được đưa vào RTM cuối cùng của SQL Server 2012.

Trong CTP1, tôi đã gửi một mục Connect yêu cầu một hành động được tạo để cho phép thu thập kế hoạch thực thi thực tế với các sự kiện trong SQL Server 2012. Mục tiêu là có thể sử dụng các sự kiện module_end hoặc sql_statement_completed để xác định thời điểm thực thi một thủ tục hoặc câu lệnh vượt quá thời lượng bình thường của nó. Ví dụ, trong kịch bản về độ nhạy tham số, trong đó một kế hoạch ít lý tưởng hơn được tạo cho các giá trị tham số bình thường, sự kiện có thể được sử dụng để thu thập kế hoạch thực thi thực tế cho câu lệnh đó thông qua một hành động. Đáp lại, nhóm SQL Server đã thêm cột thời lượng và cpu_time vào sự kiện query_post_execution_showplan để cho phép các định nghĩa vị từ chỉ thu thập sự kiện này cho các trường hợp đó.

Rất tiếc, điều này không mang lại những lợi ích tương tự như việc triển khai như một hành động sẽ có đối với hiệu suất. Trong phần còn lại của bài đăng này, tôi sẽ giải thích lý do tại sao.

Tác động đến hiệu suất

Vào thời điểm tôi thực hiện kiểm tra cho bài viết trước của mình, tôi cũng đã kiểm tra chi phí liên quan đến sự kiện query_post_execution_showplan, chủ yếu vì tôi thực sự quan tâm đến việc sử dụng nó trong một vài hệ thống sản xuất khách hàng và trước khi thực hiện, tôi cần hiểu những gì loại tác động mà sự kiện sẽ có đối với khối lượng công việc của họ. Tôi thực sự bị mất tinh thần với kết quả nhận được từ các bài kiểm tra ban đầu của mình và sau khi nhờ Aaron Bertrand xác thực kết quả của tôi bằng cách sử dụng bộ khai thác kiểm tra nội bộ của SQL Sentry, tôi đã gửi một mục Connect khác báo cáo các vấn đề về hiệu suất mà sau đó đã bị đóng lại là "Theo thiết kế" .

Để kiểm tra tác động đến hiệu suất, cùng một khối lượng công việc và cấu hình phát lại phân tán từ bài viết Đo lường “Chi phí trình quan sát” của SQL Trace so với Sự kiện mở rộng đã được sử dụng. Sự khác biệt duy nhất đối với các kết quả kiểm tra được hiển thị trong bài viết này là một hệ thống máy chủ mới hơn, mạnh mẽ hơn đã được sử dụng cho môi trường VM. Các máy ảo được sử dụng hoàn toàn giống nhau, không có thay đổi về cấu hình và chúng chỉ được sao chép sang hệ thống mới, đó là lý do tại sao khối lượng công việc cơ sở có thể thực hiện phát lại nhanh hơn với Yêu cầu hàng loạt trung bình cao hơn / giây. Kết quả cơ sở được ghi lại bằng cách sử dụng cài đặt SQL Server 2012 tiêu chuẩn chỉ có phiên sự kiện system_health mặc định chạy trên máy chủ.

Để so sánh tác động hiệu suất của query_post_execution_showplan sự kiện, định nghĩa phiên sự kiện sau đã được sử dụng.

CREATE EVENT SESSION [query_post_execution_showplan Overhead]
ON SERVER
ADD EVENT sqlserver.query_post_execution_showplan(
WHERE ([duration]=(5000000)));
GO

Phiên này không thực sự thu thập dữ liệu sự kiện bằng cách sử dụng mục tiêu và sử dụng một vị từ về thời lượng cho thời lượng sự kiện bằng 5000000 micro giây hoặc thời lượng năm giây. Đối với khối lượng công việc phát lại, không có câu lệnh nào thực thi có thời lượng chính xác là năm giây, do đó, sự kiện query_post_execution_showplan không bao giờ thực sự kích hoạt trong máy chủ và mọi sự suy giảm hiệu suất hoàn toàn là kết quả của việc thu thập dữ liệu sự kiện và sau đó đánh giá vị từ. Kết quả từ các thử nghiệm được thể hiện trong Bảng 1 và biểu đồ trong Biểu đồ 2.

Bảng 1 - chi phí sự kiện query_post_execution

Biểu đồ 2 - chi phí sự kiện query_post_execution

Đối với vòng kiểm tra này, hiệu suất của khối lượng công việc giảm khoảng 30% chỉ bằng cách kích hoạt sự kiện này trong một phiên sự kiện, mặc dù nó sẽ không kích hoạt cho bất kỳ sự kiện nào đang được phát lại trên máy chủ. Sự xuống cấp tổng thể sẽ phụ thuộc vào khối lượng công việc thực tế của máy chủ và điều quan trọng cần lưu ý là loạt bài kiểm tra này phản ánh nhiều trường hợp xấu nhất vì Phát lại phân tán được chạy ở chế độ căng thẳng và việc sử dụng CPU trên Máy chủ SQL đã được chốt ở mức trung bình 94% trong các bài kiểm tra.

Hiểu tác động của hiệu suất

Lý do mà sự kiện này áp đặt chi phí đáng kể như vậy đối với hiệu suất có thể được giải thích từ vòng đời của sự kiện trong Sự kiện mở rộng. Khi gặp phải điểm quan trọng trong mã SQL Server liên quan đến một sự kiện trong khi thực thi, mã sẽ thực hiện kiểm tra Boolean rất nhanh để xác định xem sự kiện có được bật trong bất kỳ phiên sự kiện đang hoạt động nào trên máy chủ hay không. Nếu sự kiện được bật cho một phiên sự kiện đang hoạt động, tất cả các cột dữ liệu được liên kết với sự kiện sẽ được thu thập, bao gồm mọi cột có thể tùy chỉnh đã được bật. Tại thời điểm này, sự kiện sẽ đánh giá bất kỳ vị từ nào cho các phiên sự kiện đang hoạt động đang thu thập sự kiện để xác định xem sự kiện có thực sự kích hoạt hoàn toàn hay không.

Đối với sự kiện query_post_exection_showplan, tất cả tác động đến hiệu suất là từ chi phí liên quan đến việc thu thập dữ liệu. Ngay cả trong trường hợp có một vị từ có thời lượng bằng năm giây, chỉ bằng cách bật sự kiện trong một phiên sự kiện, nó phải thu thập Showplan XML cho mọi câu lệnh thực thi trên máy chủ chỉ để có thể đánh giá vị từ và sau đó xác định rằng sự kiện sẽ không kích hoạt. Vì lý do này, nên tránh sự kiện query_post_execution_showplan đối với khối lượng công việc sản xuất. Đối với khối lượng công việc phát lại thử nghiệm, sự kiện phải được đánh giá khoảng 440.000 lần, mặc dù nó không thực sự kích hoạt đối với khối lượng công việc và phiên sự kiện đang được thử nghiệm vì không có sự kiện phát lại nào có thời lượng chính xác năm giây. Thông tin về số lượng sự kiện đã được thu thập bằng cách thêm mục tiêu event_counter vào phiên sự kiện và xóa vị từ thời lượng, sau đó kiểm tra lại khối lượng công việc phát lại với định nghĩa phiên sau đây.

CREATE EVENT SESSION [query_post_execution_showplan Overhead] 
ON SERVER
ADD EVENT sqlserver.query_post_execution_showplan
ADD TARGET package0.event_counter;
GO

So sánh với Sự kiện Kích hoạt Nhanh chóng

Để cung cấp hệ quy chiếu về tác động hiệu suất này, chúng ta có thể xem xét chi phí của việc bật một tập hợp các sự kiện thường xuyên thực thi trong máy chủ và thực hiện cùng một khối lượng công việc phát lại. Hai trong số các sự kiện được thực thi thường xuyên nhất trong SQL Server là sự kiện lock_acquired và lock_released. Để so sánh tổng chi phí của hai sự kiện này, có thể sử dụng phiên sự kiện sau để thu thập các sự kiện không có vị từ để mọi thực thi được thu thập và tính tần suất chúng kích hoạt bằng cách sử dụng mục tiêu event_counter.

CREATE EVENT SESSION [locking Overhead] 
ON SERVER
ADD EVENT sqlserver.lock_acquired,
ADD EVENT sqlserver.lock_released
ADD TARGET package0.event_counter;
GO

Đối với khối lượng công việc phát lại của chúng tôi, hai sự kiện này kích hoạt khoảng 111.180.000 lần. Chi phí liên quan đến việc thu thập các sự kiện này có thể được xem trong Bảng 3 và Biểu đồ 4.

Bảng 3 - Khóa so sánh chi phí

Biểu đồ 4 - So sánh tổng chi phí sự kiện

Như bạn có thể thấy từ dữ liệu, hiệu quả hoạt động của các sự kiện này thấp hơn đáng kể so với query_post_execution_showplan, mặc dù định nghĩa phiên sự kiện khóa đã được định cấu hình để cho phép tất cả các sự kiện kích hoạt trên máy chủ, tổng chi phí nói chung là dưới 1% . Hãy nhớ rằng phiên sự kiện khóa đã đánh giá lượng sự kiện tương đương với gấp 500 lần sự kiện và trong trường hợp này, tất cả các sự kiện thực sự phải kích hoạt cho phiên sự kiện, trong đó sự kiện query_post_execution_showplan thực sự không phải kích hoạt sau khi được đánh giá.

Tóm tắt

Mặc dù sự kiện query_post_execution_showplan cung cấp khả năng thu thập kế hoạch truy vấn thực tế cho một câu lệnh thực thi, tác động hiệu suất của việc thu thập dữ liệu chỉ để đánh giá sự kiện khiến nó trở thành thứ không khả thi để sử dụng trong sản xuất. Ở mức tối thiểu, chi phí phải được xem xét trước khi bạn sử dụng sự kiện này với khối lượng công việc sản xuất. Ngay cả phần mô tả sự kiện do Microsoft cung cấp cũng thừa nhận rằng sự kiện có thể có tác động đáng kể đến hiệu suất (điểm nổi bật của tôi):

Bạn có thể tìm thấy mô tả sự kiện trong cột mô tả của chế độ xem danh mục sys.dm_xe_objects hoặc trong Giao diện người dùng phiên mới như được hiển thị trong Hình 5 (phần đánh dấu của tôi):

Hình 5 - Mô tả sự kiện từ Giao diện người dùng phiên mới

Tôi khuyên bạn nên đo điểm chuẩn hiệu suất của bất kỳ sự kiện nào có cảnh báo này trong phần mô tả trước khi thực sự sử dụng nó trong môi trường sản xuất.