Khám phá các kịch bản hiệu suất

Đã hoàn thành

Để quyết định cách sử dụng các công cụ và chức năng hiệu suất, điều quan trọng là phải xem xét hiệu suất cho Azure SQL thông qua các kịch bản.

Tìm hiểu các kịch bản hiệu suất phổ biến

Một kỹ thuật phổ biến để khắc phục sự cố hiệu suất SQL Server là để kiểm tra xem một vấn đề hiệu suất là chạy (CPU cao) hoặc chờ (chờ trên một nguồn tài nguyên). Sơ đồ sau đây hiển thị cây quyết định để xác định xem sự cố hiệu suất SQL Server đang chạy hay đang chờ và cách sử dụng công cụ hiệu năng để xác định nguyên nhân và giải pháp.

Trước tiên, hãy xem mức sử dụng tài nguyên tổng thể. Đối với việc triển khai SQL Server tiêu chuẩn, bạn có thể sử dụng các công cụ như Trình giám sát Hiệu suất trong Windows hoặc công cụ hàng đầu trong Linux. Đối với Azure SQL, bạn có thể sử dụng các phương pháp sau:

• Cổng thông tin Azure/PowerShell/cảnh báo

  Azure Monitor có các số liệu tích hợp để xem mức sử dụng tài nguyên cho Azure SQL. Bạn cũng có thể thiết lập cảnh báo để tìm kiếm điều kiện sử dụng tài nguyên.

• sys.dm_db_resource_stats

  Đối với Cơ sở dữ liệu Azure SQL, bạn có thể xem DMV này để biết mức sử dụng CPU, bộ nhớ và tài nguyên I/O cho triển khai cơ sở dữ liệu. DMV này chụp nhanh dữ liệu này 15 giây một lần.

• sys.server_resource_stats

  DMV này hoạt động giống như sys.dm_db_resource_stats, nhưng nó được sử dụng để xem sử dụng tài nguyên cho SQL Managed Instance cho CPU, bộ nhớ và I/O. DMV này cũng chụp ảnh tức thời 15 giây một lần.

• sys.dm_user_db_resource_governance

  Đối với Cơ sở dữ liệu Azure SQL, DMV này trả về cài đặt cấu hình và dung lượng thực tế được cơ chế quản trị tài nguyên sử dụng trong cơ sở dữ liệu hiện tại hoặc vùng đàn hồi.

• sys.dm_instance_resource_governance

  Đối với Phiên bản được Quản lý của Azure SQL, DMV này trả về thông tin tương tự như sys.dm_user_db_resource_governance, nhưng cho Phiên bản được Quản lý của SQL hiện tại.

Chạy

Nếu bạn đã xác định vấn đề là sử dụng CPU cao, điều này được gọi là một kịch bản đang chạy. Kịch bản đang chạy có thể liên quan đến các truy vấn tiêu thụ tài nguyên thông qua biên soạn hoặc thực thi. Sử dụng các công cụ sau đây để phân tích thêm:

• Kho Truy vấn

  Sử dụng báo cáo Tài nguyên Tiêu thụ Hàng đầu trong dạng xem danh mục SSMS, Kho truy vấn hoặc Thông tin chuyên sâu về Hiệu suất Truy vấn trong cổng thông tin Azure (chỉ cơ sở dữ liệu Azure SQL) để tìm truy vấn nào đang sử dụng nhiều tài nguyên CPU nhất.

• sys.dm_exec_requests

  Sử dụng DMV này trong Azure SQL để xem nhanh trạng thái của truy vấn hiện hoạt. Tìm kiếm các truy vấn có trạng thái RUNNABLE chờ và một loại dữ liệu SOS_SCHEDULER_YIELD để xem liệu bạn có đủ dung lượng CPU hay không.

• sys.dm_exec_query_stats

  DMV này có thể được sử dụng giống như Kho truy vấn để tìm các truy vấn tiêu thụ tài nguyên hàng đầu. Nó chỉ sẵn dùng cho các kế hoạch truy vấn được lưu vào bộ đệm ẩn, trong khi Kho Truy vấn cung cấp một bản ghi lịch sử liên tục về hiệu năng. DMV này cũng cho phép bạn tìm kế hoạch truy vấn cho truy vấn đã lưu trong bộ đệm ẩn.

• sys.dm_exec_procedure_stats

  DMV này cung cấp thông tin giống sys.dm_exec_query_stats, ngoại trừ thông tin hiệu suất có thể được xem ở cấp thủ tục lưu trữ.

  Sau khi bạn xác định truy vấn hoặc truy vấn nào đang tiêu thụ nhiều tài nguyên nhất, bạn có thể phải kiểm tra xem bạn có đủ tài nguyên CPU cho khối lượng công việc của mình hay không. Bạn có thể gỡ lỗi kế hoạch truy vấn bằng các công cụ như ghi hồ sơ truy vấn nhẹ, câu lệnh SET, Kho Truy vấn hoặc theo dõi sự kiện mở rộng.

Chờ đợi

Nếu vấn đề của bạn dường như không phải là một mức sử dụng tài nguyên CPU cao, đó có thể là vấn đề hiệu suất liên quan đến việc chờ đợi trên một tài nguyên. Các kịch bản liên quan đến việc chờ đợi tài nguyên bao gồm:

• I/O chờ
• Khóa chờ
• Chốt chờ
• Giới hạn vùng đệm
• Cấp bộ nhớ
• Loại trừ bộ đệm ẩn kế hoạch

Để thực hiện phân tích về các kịch bản chờ đợi, bạn thường xem các công cụ sau:

• sys.dm_os_wait_stats

  Dùng DMV này để xem các kiểu chờ hàng đầu cho cơ sở dữ liệu hoặc phiên bản. Điều này có thể hướng dẫn bạn về hành động cần thực hiện tiếp theo, tùy thuộc vào các loại chờ đợi hàng đầu.

• sys.dm_exec_requests

  Sử dụng DMV này để tìm các loại chờ đợi cụ thể cho truy vấn hiện hoạt để xem họ đang chờ đợi tài nguyên nào. Đây có thể là kịch bản chặn tiêu chuẩn, chờ người dùng khác khóa.

• sys.dm_os_waiting_tasks

  Bạn có thể sử dụng DMV này để tìm các loại chờ cho một tác vụ cụ thể cho một truy vấn cụ thể hiện đang thực thi, có thể để xem lý do tại sao nó mất nhiều thời gian hơn bình thường. sys.dm_os_waiting_tasks số liệu thống kê chờ trực tiếp được sys.dm_os_wait_stats tổng hợp theo thời gian.

• Kho Truy vấn

  Kho Truy vấn cung cấp báo cáo và dạng xem ca-ta-lô hiển thị phép tổng hợp các chờ hàng đầu để thực hiện kế hoạch truy vấn. Điều quan trọng là phải biết rằng một chờ đợi CPU tương đương với một sự cố chạy của bạn.

Các kịch bản dành riêng cho Azure SQL

Có một số kịch bản hiệu suất, cả đang chạy và đang chờ, dành riêng cho Azure SQL. Chúng bao gồm quản trị nhật ký, giới hạn bộ thực hiện, gặp phải chờ cho các tầng dịch vụ Quan trọng của Doanh nghiệp và chờ triển khai siêu cấp cụ thể.

Quản trị nhật ký

Azure SQL có thể sử dụng quản trị tốc độ nhật ký để thực thi giới hạn tài nguyên đối với việc sử dụng nhật ký giao dịch. Bạn có thể cần thực thi này để đảm bảo giới hạn tài nguyên và đáp ứng SLA đã hứa. Quản trị nhật ký có thể được nhìn thấy từ các loại chờ đợi sau:

• LOG_RATE_GOVERNOR: chờ Cơ sở dữ liệu Azure SQL
• POOL_LOG_RATE_GOVERNOR: đợi Elastic Pools
• INSTANCE_LOG_GOVERNOR: chờ Phiên bản được Quản lý của Azure SQL
• HADR_THROTTLE_LOG_RATE*: chờ doanh nghiệp quan trọng và địa lý nhân rộng độ trễ

Giới hạn nhân viên

SQL Server sử dụng một nhóm luồng trình làm việc nhưng có giới hạn về số lượng tối đa công nhân. Các ứng dụng có số lượng người dùng đồng thời lớn có thể tiếp cận giới hạn bộ thực thi dành cho Cơ sở dữ liệu Azure SQL và Phiên bản được Quản lý của SQL:

• Cơ sở dữ liệu Azure SQL có các giới hạn dựa trên cấp và kích cỡ dịch vụ. Nếu bạn vượt quá giới hạn này, một truy vấn mới sẽ nhận được lỗi.
• Tại thời điểm hiện tại, Phiên bản được Quản lý của SQL sử dụng max worker threads, vì vậy, những người lao động vượt quá giới hạn này có thể THREADPOOL phải chờ.

Doanh nghiệp quan trọng HADR chờ đợi

Nếu bạn sử dụng bậc dịch vụ Quan trọng của Doanh nghiệp, bạn có thể bất ngờ thấy các loại chờ đợi sau:

• HADR_SYNC_COMMIT
• HADR_DATABASE_FLOW_CONTROL
• HADR_THROTTLE_LOG_RATE_SEND_RECV

Mặc dù những chờ đợi này có thể không làm chậm ứng dụng của bạn, bạn có thể không mong đợi để xem những. Chúng thường dành riêng cho việc sử dụng nhóm luôn bật sẵn sàng. Các tầng Quan trọng của Doanh nghiệp sử dụng công nghệ nhóm tính khả dụng để thực hiện các tính năng SLA và tính khả dụng của tầng dịch vụ Quan trọng của Doanh nghiệp, vì vậy những loại chờ đợi này được mong đợi. Thời gian chờ đợi dài có thể cho thấy có sự tắc nghẽn, chẳng hạn như độ trễ I/O hoặc bản sao đằng sau.

Siêu cấp độ

Kiến trúc Hyperscale có thể dẫn đến một số loại chờ đợi duy nhất được tiền tố với RBIO (một chỉ báo có thể cho biết quản trị nhật ký). Ngoài ra, các DMV, chế độ xem danh mục và sự kiện mở rộng được nâng cao để hiển thị số liệu cho số lượt đọc trên máy chủ trang.

Trong bài tập tiếp theo, bạn sẽ tìm hiểu cách theo dõi và giải quyết vấn đề hiệu năng cho Azure SQL bằng cách sử dụng các công cụ và kiến thức bạn đã có được trong bài học này.