Trong bài đăng này, tôi sẽ thảo luận về một phương pháp chung để khắc phục sự cố hiệu suất CPU. Tôi thích áp dụng các phương pháp theo mặc định và tôi cũng thích xây dựng hiệu quả trong cách tôi khắc phục sự cố dựa trên kinh nghiệm trong quá khứ. Nếu không có một khuôn khổ chung, việc bỏ sót nguyên nhân gốc rễ thực sự ở giữa một cuộc khủng hoảng trở nên quá dễ dàng.
Các bước tôi sẽ mô tả trong bài đăng này như sau:
- Xác định vấn đề
- Xác thực các điều kiện hiện tại
- Trả lời “Có phải là SQL Server không”?
- Xác định người tiêu dùng CPU
- Khớp mẫu và giải quyết
Bài viết này sẽ trình bày từng bước này. Tôi sẽ đưa ra giả định rằng bạn có thể không sử dụng công cụ giám sát của bên thứ ba. Nếu đúng như vậy, khuôn khổ ở đây vẫn được áp dụng, nhưng các nguồn dữ liệu và công cụ theo ý của bạn sẽ khác với những gì tôi mô tả.
Xác định vấn đề
Đầu tiên chúng ta cần xác định phạm vi vấn đề. Khi ai đó đến gặp bạn và nói rằng họ đang gặp vấn đề về hiệu suất CPU, điều này có thể có nghĩa là bất kỳ điều gì khác nhau. Vì vậy, nhiệm vụ đầu tiên là hiểu bản chất của vấn đề hiệu suất CPU hiện tại là gì.
Một số danh mục phổ biến bao gồm:
- Tính khả dụng bị ảnh hưởng do "các CPU được cố định". Ví dụ:tất cả các bộ lập lịch chạy 100% trên bảng và thông lượng bị đình trệ hoặc giảm đáng kể.
- Suy giảm hiệu suất do sử dụng CPU "cao hơn bình thường". Vì vậy, chúng tôi không cố định, nhưng CPU của bạn đang chạy với tỷ lệ phần trăm cao hơn mức bình thường và có lẽ điều đó đang ảnh hưởng đến hiệu suất.
- Một loại phổ biến khác của vấn đề hiệu suất CPU là tình huống "kẻ thắng và người thua" trong đó khối lượng công việc đang cạnh tranh với nhau. Có lẽ bạn có khối lượng công việc OLTP đang gặp phải thông lượng giảm do truy vấn báo cáo thực thi song song.
- Một vấn đề khác có thể là gặp phải điểm giới hạn - nơi mà các giới hạn về dung lượng tổng thể và khả năng mở rộng của hệ thống của bạn bị ảnh hưởng ở một điểm nhất định.
Tôi đề cập đến các danh mục quá vòm này như một điểm khởi đầu, nhưng tôi biết rằng thường có thể có sự phụ thuộc nặng nề đối với những vấn đề này và một phân loại có thể trộn lẫn vào phân loại kia. Như đã nói, bước đầu tiên là xác định các triệu chứng và vấn đề càng rõ ràng càng tốt.
Xác thực các điều kiện hiện tại
Cho dù sự cố đã xảy ra trong quá khứ hay đang xảy ra ngay bây giờ, điều quan trọng là phải có được càng nhiều thông tin cơ bản về hệ thống, khối lượng công việc và cấu hình càng tốt. Nếu bạn đang sử dụng đường cơ sở và sách chạy, lý tưởng nhất là bạn đang theo dõi phần lớn thông tin này. Nếu không, hãy tự hỏi bản thân xem bạn có thể nhận được câu trả lời cho những câu hỏi này nhanh như thế nào vào lúc 2 giờ sáng giữa khủng hoảng.
Các phần phụ sau đây bao gồm các điểm dữ liệu quan trọng mà tôi thường quan tâm đến vấn đề hiệu suất CPU.
- Có bao nhiêu ổ cắm và lõi?
- Siêu phân luồng có được bật không?
- Mô hình, kiến trúc bộ xử lý (32-bit / 64-bit) là gì?
- Đây có phải là khách ảo không?
- Nếu vậy, bây giờ bạn cũng sẽ quan tâm đến thông tin chi tiết về máy chủ và những khách ảo khác mà bạn đang chia sẻ tài nguyên.
- Có bất kỳ cài đặt nào liên quan đến CPU có hiệu lực không?
- Ví dụ:CPU Hyper-V
- Có bao nhiêu vCPU được phân bổ cho các khách?
- Khách này có bao nhiêu vCPU?
- Khách có phải gần đây đã di chuyển sang máy chủ mới trước sự cố không?
- Cài đặt mức độ song song tối đa
- Ngưỡng chi phí cho tùy chọn song song
- Cài đặt sở thích của bộ xử lý
- Cài đặt tăng mức độ ưu tiên
- Cài đặt số lượng công nhân tối đa
- Cài đặt gộp nhẹ
- Cài đặt tùy chọn nguồn là gì? (Cấp hệ điều hành, Máy chủ VM hoặc được điều khiển bằng BIOS)
- Hiệu suất cao, Cân bằng, Tiết kiệm điện năng?
- Nó có được định cấu hình ngoài cài đặt mặc định không?
- Bạn có thấy bất kỳ cảnh báo hoặc lỗi bất thường nào không?
Chi tiết máy chủ vật lý
Chi tiết máy chủ ảo
Dự trữ, Bảo lưu CPU VMware, Trọng lượng Tương đối CPU Hyper-V và Chia sẻ CPU VMware.
Cài đặt cấu hình phiên bản SQL Server
Ba cấu hình đầu tiên có thể cần thảo luận thêm. Hiếm khi có những điều khoản tuyệt đối liên quan đến những cài đặt này.
Về ba cài đặt cuối cùng, chẳng hạn như "tăng mức độ ưu tiên", nếu tôi thấy rằng chúng ở giá trị không mặc định, tôi chắc chắn sẽ thúc đẩy thêm thông tin cơ bản và lịch sử.
Cài đặt tùy chọn nguồn CPU
Cài đặt Power-option bên dưới “Hiệu suất cao” vẫn rất phổ biến và không nên bỏ qua đối với các máy chủ lưu trữ các phiên bản SQL Server.
Cấu hình thống đốc tài nguyên
Tôi vẫn thấy rằng hiếm khi bắt gặp khách hàng sử dụng tính năng này, nhưng rất dễ dàng để xác nhận xem nó có đang được sử dụng hay không và sẽ đáng giá so với thời điểm nó thực sự được định cấu hình vượt quá mặc định.
Nhật ký lỗi SQL Server và nhật ký sự kiện Windows
Tại sao lại tìm lỗi và nhật ký sự kiện để tìm sự cố CPU? Đôi khi sự cố ngược dòng có thể gây ra sự cố hiệu suất hạ lưu trong SQL Server. Bạn không muốn mất thời gian điều chỉnh truy vấn hoặc thêm chỉ mục mới khi bạn đang ngược dòng, vấn đề nguyên nhân gốc là vấn đề xuống cấp thành phần phần cứng.
Trả lời “Có phải là SQL Server không?”
Nghe có vẻ rõ ràng khi tôi hỏi, nhưng bạn thực sự không muốn mất nhiều thời gian để khắc phục sự cố CPU cao trong SQL Server nếu thủ phạm thực sự không phải là SQL Server.
Thay vào đó, hãy nhanh chóng kiểm tra xem quá trình nào đang tiêu tốn nhiều CPU nhất. Có một số tùy chọn để lựa chọn, bao gồm:
- Quy trình:% Thời gian Người dùng (chế độ người dùng)
- Quy trình:% Thời gian Đặc quyền (chế độ hạt nhân)
- Trình quản lý Tác vụ
- Trình khám phá quy trình
- Thông tin CPU gần đây qua sys.dm_os_ring_buffers hoặc phiên tình trạng hệ thống cho các phiên bản SQL Server cụ thể đang chạy trên hệ thống
Nếu đó là SQL Server và bạn có nhiều phiên bản SQL Server để lựa chọn, hãy đảm bảo rằng bạn đang khắc phục sự cố đúng phiên bản SQL Server trên máy chủ. Có một số cách để thực hiện việc này, bao gồm cả việc sử dụng SELECT SERVERPROPERTY('processid') để lấy PID và sau đó liên kết nó với Trình quản lý tác vụ hoặc Trình khám phá quy trình.
Sau khi bạn xác nhận đó là Máy chủ SQL, bạn có thấy thời gian người dùng hoặc thời gian đặc quyền (nhân) cao không? Một lần nữa điều này có thể được xác nhận thông qua Process:% Privileged Time (đối tượng sqlservr) và cả Windows Task Manager hoặc Process Explorer.
Mặc dù các vấn đề về thời gian nhân cao hiếm khi xảy ra, nhưng chúng vẫn yêu cầu các đường dẫn khắc phục sự cố khác với các vấn đề khắc phục sự cố CPU thời gian người dùng tiêu chuẩn. Một số nguyên nhân tiềm ẩn dẫn đến thời gian nhân cao bao gồm trình điều khiển bộ lọc bị lỗi (dịch vụ chống vi-rút, mã hóa), cập nhật chương trình cơ sở và trình điều khiển lỗi thời hoặc bị thiếu hoặc các thành phần I / O bị lỗi.
Xác định người tiêu dùng CPU
Sau khi bạn đã xác thực phiên bản SQL Server nào đang thúc đẩy mức sử dụng CPU theo thời gian của người dùng trên hệ thống, có rất nhiều ví dụ truy vấn soạn sẵn trên web mà bạn có thể sử dụng.
Dưới đây là danh sách các DMV mà mọi người thường sử dụng dưới nhiều hình thức khác nhau khi gặp sự cố về hiệu suất. Tôi đã cấu trúc phần này theo định dạng Hỏi &Đáp để giúp định hình lý do tại sao bạn muốn truy cập chúng.
- sys.dm_exec_requests
- sys.dm_exec_sql_text
- sys.dm_exec_sessions
- sys.dm_exec_connections
- sys.dm_exec_query_plan
- sys.dm_os_waiting_tasks
- sys.dm_exec_query_stats
- Tổng hợp theo total_worker_time
- Xác định giá trị trung bình với thực hiện_count
- Nếu khối lượng công việc đặc biệt, bạn có thể nhóm theo query_hash
- Sử dụng plan_handle với sys.dm_exec_query_plan để lấy kế hoạch
- sys.dm_os_tasks
- Được sắp xếp theo session_id, request_id
- sys.dm_exec_query_plan
- Xem xét các nhà khai thác kế hoạch - nhưng hãy nhớ rằng đây chỉ là kế hoạch ước tính
- sys.dm_exec_query_stats
- Lọc total_elapsed_time nhỏ hơn total_worker_time
- Nhưng lưu ý rằng điều này có thể là một phủ định sai đối với các tình huống chặn - trong đó thời lượng bị tăng cao do chờ đợi tài nguyên
Những yêu cầu nào đang được thực hiện ngay bây giờ và trạng thái của chúng là gì?
Nó đang thực thi cái gì?
Nó đến từ đâu?
Kế hoạch ước tính của nó là gì? (nhưng hãy cẩn thận khi băm nhỏ xml trên một hệ thống đã bị ràng buộc bởi CPU)
Ai đang đợi tài nguyên và họ đang đợi gì?
Truy vấn nào chiếm nhiều thời gian CPU nhất kể từ lần khởi động lại gần đây nhất?
Truy vấn này có sử dụng song song không?
Khớp mẫu và giải quyết
Có thể bạn đang cười với bước cụ thể này - vì bước này có thể liên quan nhiều nhất (và là một lý do khác khiến các chuyên gia SQL Server được tuyển dụng hiệu quả). Có một số mẫu và độ phân giải liên quan khác nhau - vì vậy tôi sẽ kết thúc bài đăng này với danh sách các trình điều khiển vấn đề hiệu suất CPU phổ biến hơn mà tôi đã thấy trong vài năm qua:
- Hoạt động I / O cao (và theo kinh nghiệm của tôi, đây là trình điều khiển phổ biến nhất của CPU)
- Các vấn đề về ước tính số lượng (và chất lượng kế hoạch truy vấn kém liên quan)
- Song song không mong muốn
- Biên dịch / biên dịch lại quá mức
- Các cuộc gọi UDF chuyên sâu về tính toán, các hoạt động cắt nhỏ
- Các thao tác hàng từng hàng
- Các hoạt động bảo trì đồng thời (ví dụ:CẬP NHẬT số liệu thống kê với FULLSCAN)
Mỗi lĩnh vực tôi đã xác định có một khối lượng lớn công việc liên quan để nghiên cứu. Về tài nguyên tổng hợp, tôi vẫn nghĩ một trong những tài nguyên tốt hơn vẫn là bài báo kỹ thuật “Khắc phục sự cố hiệu suất trong SQL Server 2008” được viết bởi Sunil Agarwal, Boris Baryshnikov, Keith Elmore, Juergen Thomas, Kun Cheng và Burzin Patel.
Tóm tắt
Như với bất kỳ phương pháp luận nào, có những ranh giới cho việc sử dụng nó và những lĩnh vực mà bạn được chứng minh trong việc ứng biến. Xin lưu ý rằng tôi không đề xuất các bước tôi mô tả trong bài đăng này được sử dụng như một khuôn khổ cứng nhắc, mà thay vào đó, hãy coi đó là điểm khởi động cho các nỗ lực khắc phục sự cố của bạn. Ngay cả những chuyên gia SQL Server có kinh nghiệm cao cũng có thể mắc lỗi mới bắt đầu hoặc bị thiên vị bởi những trải nghiệm khắc phục sự cố gần đây hơn của họ, vì vậy việc có một phương pháp luận tối thiểu có thể giúp tránh khắc phục sự cố sai.
