Đo lường “Chi phí của trình quan sát” của SQL Trace so với Sự kiện mở rộng

SQL Server cung cấp hai phương pháp thu thập dữ liệu chẩn đoán và khắc phục sự cố về khối lượng công việc được thực thi trên máy chủ:SQL Trace và Extended Events. Bắt đầu từ SQL Server 2012, triển khai Sự kiện mở rộng cung cấp khả năng thu thập dữ liệu có thể so sánh với SQL Trace và có thể được sử dụng để so sánh chi phí phát sinh bởi hai tính năng này. Trong bài viết này, chúng ta sẽ xem xét so sánh "chi phí quan sát" xảy ra khi sử dụng SQL Trace và Sự kiện mở rộng trong các cấu hình khác nhau để xác định tác động hiệu suất mà việc thu thập dữ liệu có thể có đối với khối lượng công việc của chúng tôi thông qua việc sử dụng khối lượng công việc phát lại nắm bắt và phát lại phân tán.

Môi trường thử nghiệm

Môi trường thử nghiệm bao gồm sáu máy ảo, một bộ điều khiển miền, một máy chủ phiên bản Doanh nghiệp SQL Server 2012 và bốn máy chủ khách có cài đặt dịch vụ khách Phát lại Phân tán trên chúng. Các cấu hình máy chủ lưu trữ khác nhau đã được kiểm tra cho bài viết này và các kết quả tương tự là kết quả từ ba cấu hình khác nhau đã được kiểm tra dựa trên tỷ lệ tác động. Máy chủ phiên bản SQL Server Enterprise được định cấu hình với 4 vCPU và 4GB RAM. Năm máy chủ còn lại được cấu hình với 1 vCPU và 1GB RAM. Dịch vụ bộ điều khiển phát lại phân tán đã được chạy trên máy chủ phiên bản Doanh nghiệp SQL Server 2012 vì nó yêu cầu giấy phép Doanh nghiệp để sử dụng nhiều máy khách để phát lại.

Khối lượng công việc kiểm tra

Khối lượng công việc thử nghiệm được sử dụng để chụp lại là khối lượng công việc AdventureWorks Books Online mà tôi đã tạo vào năm ngoái để tạo khối lượng công việc giả cho SQL Server. Khối lượng công việc này sử dụng các truy vấn mẫu từ Books Online đối với dòng cơ sở dữ liệu AdventureWorks và được điều khiển bởi PowerShell. Khối lượng công việc được thiết lập trên mỗi máy khách trong số bốn máy khách phát lại và chạy với tổng số bốn kết nối đến Máy chủ SQL từ mỗi máy chủ khách để tạo bản ghi theo dõi phát lại 1GB. Dấu vết phát lại được tạo bằng cách sử dụng mẫu TSQL_Replay từ SQL Server Profiler, được xuất sang tập lệnh và được định cấu hình dưới dạng dấu vết phía máy chủ cho một tệp. Khi tệp theo dõi phát lại được ghi lại, nó đã được xử lý trước để sử dụng với Phát lại được phân phối và sau đó dữ liệu phát lại được sử dụng làm khối lượng công việc phát lại cho tất cả các thử nghiệm.

Cấu hình phát lại

Hoạt động phát lại đã được định cấu hình để sử dụng cấu hình chế độ căng thẳng để thúc đẩy lượng tải tối đa so với phiên bản SQL Server thử nghiệm. Ngoài ra, cấu hình sử dụng thang thời gian suy nghĩ và kết nối giảm, điều chỉnh tỷ lệ thời gian giữa thời điểm bắt đầu theo dõi phát lại và thời điểm một sự kiện thực sự xảy ra với khi nó được phát lại trong hoạt động phát lại, để cho phép các sự kiện được phát lại tại quy mô tối đa. Thang đo ứng suất cho lần phát lại cũng được định cấu hình cho mỗi lần quay. Chi tiết của tệp cấu hình cho hoạt động phát lại như sau:

<?xml version="1.0" encoding="utf-8"?>
<Options>
  <ReplayOptions>
    <Server>SQL2K12-SVR1</Server>
    <SequencingMode>stress</SequencingMode>
    <ConnectTimeScale>1</ConnectTimeScale>
    <ThinkTimeScale>1</ThinkTimeScale>
    <HealthmonInterval>60</HealthmonInterval>
    <QueryTimeout>3600</QueryTimeout>
    <ThreadsPerClient>255</ThreadsPerClient>
    <EnableConnectionPooling>Yes</EnableConnectionPooling>
    <StressScaleGranularity>spid</StressScaleGranularity>
  </ReplayOptions>
  <OutputOptions>
    <ResultTrace>
      <RecordRowCount>No</RecordRowCount>
      <RecordResultSet>No</RecordResultSet>
    </ResultTrace>
  </OutputOptions>
</Options>

Trong mỗi hoạt động phát lại, bộ đếm hiệu suất được thu thập trong khoảng thời gian năm giây cho các bộ đếm sau:

• Bộ xử lý \% Thời gian của Bộ xử lý \ _Tổng số
• SQL Server \ Thống kê SQL \ Yêu cầu hàng loạt / giây

Các bộ đếm này sẽ được sử dụng để đo tải tổng thể của máy chủ và đặc điểm thông lượng của từng bài kiểm tra để so sánh.

Cấu hình thử nghiệm

Tổng cộng bảy cấu hình khác nhau đã được thử nghiệm với Phát lại phân tán:

• Đường cơ sở
• Theo dõi phía máy chủ
• Hồ sơ trên máy chủ
• Hồ sơ từ xa
• Sự kiện được mở rộng sang event_file
• Sự kiện mở rộng cho ring_buffer
• Sự kiện được mở rộng sang event_stream

Mỗi thử nghiệm được lặp lại ba lần để đảm bảo rằng các kết quả nhất quán giữa các thử nghiệm khác nhau và cung cấp một tập hợp kết quả trung bình để so sánh. Đối với các thử nghiệm cơ sở ban đầu, không có bộ sưu tập dữ liệu bổ sung nào được định cấu hình cho phiên bản SQL Server, nhưng bộ sưu tập dữ liệu mặc định đi kèm với SQL Server 2012 vẫn được bật:theo dõi mặc định và phiên sự kiện system_health. Điều này phản ánh cấu hình chung của hầu hết các Máy chủ SQL, vì thông thường người ta không nên tắt theo dõi mặc định hoặc phiên system_health do những lợi ích mà chúng cung cấp cho người quản trị cơ sở dữ liệu. Thử nghiệm này được sử dụng để xác định đường cơ sở tổng thể để so sánh với các thử nghiệm khi thu thập dữ liệu bổ sung đang được thực hiện. Các thử nghiệm còn lại dựa trên mẫu TSQL_SPs đi kèm với SQL Server Profiler và thu thập các sự kiện sau:

• Kiểm tra bảo mật \ Đăng nhập kiểm tra
• Kiểm tra bảo mật \ Đăng xuất kiểm tra
• Phiên \ Hiện tạiConnection
• Thủ tục được lưu trữ \ RPC:Đang bắt đầu
• Thủ tục được Lưu trữ \ SP:Đã hoàn thành
• Thủ tục được Lưu trữ \ SP:Đang bắt đầu
• Thủ tục được Lưu trữ \ SP:StmtStarting
• TSQL \ SQL:BatchStarting

Mẫu này được chọn dựa trên khối lượng công việc được sử dụng cho các bài kiểm tra, chủ yếu là các lô SQL được SQL:BatchStarting ghi lại sự kiện và sau đó là một số sự kiện bằng cách sử dụng các phương thức khác nhau của hierarchyid , được ghi lại bởi SP:Starting , SP:StmtStarting và SP:Completed sự kiện. Tập lệnh theo dõi phía máy chủ được tạo từ mẫu bằng cách sử dụng chức năng xuất trong SQL Server Profiler và các thay đổi duy nhất được thực hiện đối với tập lệnh là đặt maxfilesize tham số thành 500MB, cho phép cuộn qua tệp theo dõi và cung cấp tên tệp mà dấu vết đã được ghi vào đó.

Thử nghiệm thứ ba và thứ tư đã sử dụng SQL Server Profiler để thu thập các sự kiện giống như theo dõi phía máy chủ để đo lường hiệu suất chi phí theo dõi bằng ứng dụng Profiler. Các thử nghiệm này được chạy bằng SQL Profiler cục bộ trên SQL Server và từ xa từ một máy khách riêng biệt để xác định xem có sự khác biệt về chi phí hay không bằng cách để Profiler chạy cục bộ hoặc từ xa.

Các thử nghiệm cuối cùng sử dụng Sự kiện mở rộng đã thu thập các sự kiện giống nhau và các cột giống nhau dựa trên phiên sự kiện được tạo bằng cách sử dụng tập lệnh chuyển đổi Theo dõi sự kiện mở rộng của tôi cho SQL Server 2012. Các thử nghiệm bao gồm đánh giá event_file, ring_buffer và nhà cung cấp phát trực tuyến mới trong SQL Server 2012 riêng biệt để xác định chi phí mà mỗi mục tiêu có thể áp đặt lên hiệu suất của máy chủ. Ngoài ra, phiên sự kiện đã được định cấu hình với các tùy chọn bộ đệm bộ nhớ mặc định, nhưng đã được thay đổi để chỉ định NO_EVENT_LOSS cho EVENT_RETENTION_MODE tùy chọn cho các bài kiểm tra event_file và ring_buffer để khớp hành vi của Trace phía máy chủ với một tệp, điều này cũng đảm bảo không mất sự kiện.

Kết quả

Ngoại trừ một ngoại lệ, kết quả của các bài kiểm tra không có gì đáng ngạc nhiên. Thử nghiệm cơ bản có thể thực hiện khối lượng công việc phát lại trong mười ba phút ba mươi lăm giây và đạt trung bình 2345 yêu cầu hàng loạt mỗi giây trong các thử nghiệm. Với tính năng Theo dõi phía máy chủ đang chạy, hoạt động phát lại hoàn tất trong 16 phút 40 giây, giảm 18,1% hiệu suất. Theo dõi hồ sơ có hiệu suất kém nhất nói chung và cần 149 phút khi Hồ sơ được chạy cục bộ trên máy chủ và 123 phút 20 giây khi Hồ sơ được chạy từ xa, mang lại hiệu suất giảm lần lượt là 90,8% và 87,6%. Các bài kiểm tra Sự kiện mở rộng có hiệu suất tốt nhất, mất 15 phút 15 giây cho tệp event_file và 15 phút 40 giây cho mục tiêu ring_buffer, dẫn đến hiệu suất giảm 10,4% và 11,6%. Kết quả trung bình cho tất cả các thử nghiệm được hiển thị trong Bảng 1 và biểu đồ trong Hình 2:

Bảng 1 - Kết quả trung bình của tất cả các bài kiểm tra

Hình 2 - Biểu đồ kết quả

Thử nghiệm phát trực tuyến Sự kiện mở rộng không phải là một kết quả hoàn toàn công bằng trong bối cảnh các thử nghiệm đã được chạy và yêu cầu giải thích thêm một chút để hiểu kết quả. Từ kết quả bảng, chúng ta có thể thấy rằng các bài kiểm tra phát trực tuyến cho Sự kiện mở rộng đã hoàn thành trong mười sáu phút ba mươi lăm giây, tương đương với 34,1% suy giảm hiệu suất. Tuy nhiên, nếu chúng ta phóng to biểu đồ và thay đổi tỷ lệ của nó, như thể hiện trong Hình 3, chúng ta sẽ thấy rằng việc phát trực tuyến có tác động lớn hơn nhiều đến hiệu suất ban đầu và sau đó bắt đầu hoạt động theo cách tương tự như các bài kiểm tra Sự kiện mở rộng khác :

Hình 3 - Đã phóng to kết quả

Giải thích cho điều này được tìm thấy trong thiết kế của mục tiêu phát trực tuyến Sự kiện mở rộng mới trong SQL Server 2012. Nếu bộ đệm bộ nhớ trong cho event_stream đầy và không được ứng dụng khách sử dụng đủ nhanh, Database Engine sẽ buộc ngắt kết nối event_stream để ngăn ảnh hưởng nghiêm trọng đến hiệu suất máy chủ. Điều này dẫn đến lỗi trong SQL Server 2012 Management Studio tương tự như lỗi trong Hình 4:

Hình 4 - event_stream bị ngắt kết nối bởi máy chủ

Kết luận

Tất cả các phương pháp thu thập dữ liệu chẩn đoán từ SQL Server đều có "chi phí quan sát" được liên kết với chúng và có thể ảnh hưởng đến hiệu suất của khối lượng công việc dưới tải nặng. Đối với hệ thống chạy trên SQL Server 2012, Sự kiện mở rộng cung cấp ít chi phí nhất và cung cấp các khả năng tương tự cho các sự kiện và cột dưới dạng SQL Trace (một số sự kiện trong SQL Trace được cuộn lại thành các sự kiện khác trong Sự kiện mở rộng). Nếu SQL Trace cần thiết để thu thập dữ liệu sự kiện - có thể xảy ra trường hợp này cho đến khi các công cụ của bên thứ ba được mã hóa để tận dụng dữ liệu Sự kiện mở rộng - Trace phía máy chủ đối với một tệp sẽ mang lại ít hiệu suất nhất. SQL Server Profiler là một công cụ cần tránh sử dụng trên các máy chủ sản xuất bận rộn, thể hiện qua thời lượng tăng gấp 10 lần và giảm đáng kể thông lượng cho lần phát lại.

Mặc dù kết quả dường như có lợi cho việc chạy SQL Server Profiler từ xa khi phải sử dụng Profiler, nhưng kết luận này không thể được rút ra một cách dứt khoát dựa trên các thử nghiệm cụ thể đã được chạy trong trường hợp này. Kiểm tra bổ sung và thu thập dữ liệu sẽ phải được thực hiện để xác định xem kết quả của Hồ sơ từ xa có phải là kết quả của việc chuyển đổi ngữ cảnh thấp hơn trên phiên bản SQL Server hay không, hoặc nếu mạng giữa các máy ảo đóng vai trò tác động đến hiệu suất thấp hơn đối với bộ sưu tập từ xa. Điểm mấu chốt trong các bài kiểm tra này là chỉ ra chi phí đáng kể mà Profiler phải gánh chịu, bất kể Profiler đang được chạy ở đâu. Cuối cùng, luồng sự kiện trực tiếp trong Sự kiện mở rộng cũng có chi phí cao khi nó thực sự được kết nối trong việc thu thập dữ liệu, nhưng như được hiển thị trong các thử nghiệm, Công cụ cơ sở dữ liệu sẽ ngắt kết nối luồng trực tiếp nếu sự kiện đó bị chậm lại để ngăn tác động nghiêm trọng đến hiệu suất của máy chủ.