Ái lực không "điều chỉnh mức sử dụng CPU" (ví dụ trong trường hợp của bạn làm cho CPU hoạt động ít hơn), nó cho phép bạn tắt CPU (có lẽ để cung cấp cho một phiên bản khác trên cùng một máy) hoặc đặt CPU thành chỉ hỗ trợ I / O. Ngay cả khi bạn có nhiều CPU, bạn sẽ không thể sử dụng cái trước để trợ giúp cho mục tiêu của mình và chúng tôi không thể đoán được cái sau bởi vì chúng tôi không biết điều gì đang thúc đẩy việc sử dụng CPU của bạn quá cao. Nó có thể là do lập chỉ mục cực kỳ kém, biên soạn quá mức, sự phong phú của UDF vô hướng, đập I / O, ai biết? (Và lý do I / O có thể là nguyên nhân là nếu cơ sở dữ liệu của bạn lớn hơn 3 GB hoặc lâu hơn, nó sẽ liên tục phải trao đổi dữ liệu vào và ra khỏi bộ nhớ vùng đệm và điều này sẽ gây thiệt hại cho CPU.)
Bộ nhớ cache CPU cũng là một lỗ thỏ bạn không cần phải đi xuống. Tôi rất nghi ngờ CPU của bạn bị đập ở mức 95% vì các vấn đề với bộ đệm CPU của bạn.
Để giúp thu hẹp nguồn áp lực CPU và giả sử bạn đang sử dụng các quy trình được lưu trữ, bạn có thể xem truy vấn chẩn đoán này từ Glenn Berry ( có nguồn gốc từ đây ) - đảm bảo bạn chạy nó trong ngữ cảnh của cơ sở dữ liệu phù hợp:
-- Top Cached SPs By Total Worker time (SQL Server 2012).
-- Worker time relates to CPU cost (Query 44) (SP Worker Time)
SELECT TOP (25)
p.name AS [SP Name],
qs.total_worker_time AS [TotalWorkerTime],
qs.total_worker_time/qs.execution_count AS [AvgWorkerTime],
qs.execution_count,
ISNULL(qs.execution_count/DATEDIFF(Second, qs.cached_time, GETDATE()), 0)
AS [Calls/Second],
qs.total_elapsed_time,
qs.total_elapsed_time/qs.execution_count AS [avg_elapsed_time],
qs.cached_time
FROM sys.procedures AS p WITH (NOLOCK)
INNER JOIN sys.dm_exec_procedure_stats AS qs WITH (NOLOCK)
ON p.[object_id] = qs.[object_id]
WHERE qs.database_id = DB_ID()
ORDER BY qs.total_worker_time DESC OPTION (RECOMPILE);
-- This helps you find the most expensive cached stored procedures from a CPU perspective
-- You should look at this if you see signs of CPU pressure
Nếu bạn không sử dụng các thủ tục được lưu trữ, thì ví dụ này từ John Samson có thể giúp cách ly các truy vấn ad hoc ( có nguồn gốc từ đây ):
SELECT TOP (25)
qs.sql_handle,
qs.execution_count,
qs.total_worker_time AS Total_CPU,
total_CPU_inSeconds = --Converted from microseconds
qs.total_worker_time/1000000,
average_CPU_inSeconds = --Converted from microseconds
(qs.total_worker_time/1000000) / qs.execution_count,
qs.total_elapsed_time,
total_elapsed_time_inSeconds = --Converted from microseconds
qs.total_elapsed_time/1000000,
st.text,
qp.query_plan
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS st
CROSS apply sys.dm_exec_query_plan (qs.plan_handle) AS qp
ORDER BY qs.total_worker_time DESC OPTION (RECOMPILE);
Bạn cũng có thể xem sp_WhoIsActive của Adam Machanic , một quy trình được lưu trữ có thể nhanh chóng phân tích tất cả các truy vấn hiện đang chạy và cho phép bạn sắp xếp nó theo cách bạn muốn (ví dụ trong trường hợp của bạn @sort_order = '[CPU] DESC').
Tuy nhiên, điều đầu tiên tôi sẽ làm - đặc biệt nếu đây thực sự là nhiệm vụ quan trọng đối với các đội tìm kiếm và cứu hộ - là mua phần cứng tốt hơn. Bạn nên có nhiều CPU và nhiều RAM hơn để phục vụ ứng dụng của mình. Bạn cũng hoàn toàn cần tính sẵn sàng cao tốt hơn (ví dụ: phân cụm, phản chiếu hoặc các nhóm sẵn có). Không có lý do gì mà việc khởi động lại máy vật lý sẽ khiến ứng dụng của bạn hoàn toàn ngoại tuyến - chúng tôi có giải pháp tốt hơn cho vấn đề đó. Và cuối cùng, tôi cho rằng "máy chủ" này chỉ có một ổ đĩa spinny. Điều này có nghĩa là tất cả I / O - từ HĐH, từ tệp dữ liệu SQL Server, tệp nhật ký, tempdb, v.v. đều đi qua một bộ điều khiển duy nhất và chia sẻ hoạt động đọc / ghi trên một ổ đĩa. Nhận nhiều đĩa hơn. Nhận SSD nếu / nơi bạn có thể. Sử dụng RAID và cố gắng truyền bá I / O càng nhiều càng tốt.
Tất cả đã nói, ném phần cứng vào vấn đề sẽ không phải là phần duy nhất của sửa chữa. Bạn cần cách ly chính xác những gì gây ra việc sử dụng CPU quá mức và sau đó tấn công những vấn đề đó bất kể bạn đang sử dụng phần cứng nào.
Cũng xem câu hỏi StackOverflow này cho một số ý tưởng khác:
/programming/945063/how-do-i-find-out-what-is-hammering-my-sql-server