Affinity ไม่ "ปรับการใช้งาน CPU" (เช่นในกรณีของคุณทำให้ CPU ทำงานน้อยลง) ช่วยให้คุณสามารถปิด CPU ได้ (อาจทำให้สามารถใช้งานอินสแตนซ์อื่นบนเครื่องเดียวกันได้) หรือตั้งค่า CPU เป็น ช่วยเหลือด้วย I / O เท่านั้น แม้ว่าคุณจะมีซีพียูหลายตัว แต่คุณก็ไม่สามารถที่จะใช้ตัวเดิมเพื่อช่วยในการตั้งเป้าหมายและมันเป็นไปไม่ได้ที่เราจะเดาได้ในตอนท้ายเพราะเราไม่รู้ว่าอะไรเป็นแรงผลักดันให้การใช้ซีพียูของคุณสูง อาจเป็นเพราะการจัดทำดัชนีที่แย่มากการรวบรวมที่มากเกินไปความอุดมสมบูรณ์ของ UDF สเกลาร์ I / O ที่ฟาดฟันใครจะรู้? (และสาเหตุของ I / O อาจเป็นสาเหตุได้ว่าหากฐานข้อมูลของคุณมีขนาดใหญ่กว่า 3 GB หรือมากกว่านั้นจะต้องสลับข้อมูลเข้าและออกจากหน่วยความจำบัฟเฟอร์พูลอย่างต่อเนื่องและสิ่งนี้จะใช้เวลากับ CPU)
แคชของ CPU เป็นช่องกระต่ายที่คุณไม่จำเป็นต้องลงไปด้วย ฉันสงสัยว่าซีพียูของคุณกำลังพุ่ง 95% เนื่องจากมีปัญหากับแคช CPU ของคุณ
เพื่อช่วย จำกัด แหล่งที่มาของแรงกดดันของ CPU และสมมติว่าคุณกำลังใช้โพรซีเดอร์ที่เก็บไว้คุณสามารถดูแบบสอบถามการวินิจฉัยนี้จาก Glenn Berry ( ที่มาจากที่นี่ ) - ตรวจสอบให้แน่ใจว่าคุณรันในบริบทของฐานข้อมูลที่ถูกต้อง:
-- 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
หากคุณไม่ได้ใช้กระบวนงานที่เก็บไว้ตัวอย่างนี้จาก John Samson สามารถช่วยแยกข้อความค้นหาเฉพาะกิจ ( ที่มาจากที่นี่ ):
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);
นอกจากนี้คุณยังสามารถดูsp_WhoIsActiveของ Adam Machanic ซึ่งเป็นกระบวนงานที่เก็บไว้ซึ่งสามารถวิเคราะห์แบบสอบถามที่กำลังทำงานอยู่ทั้งหมดได้อย่างรวดเร็วและอนุญาตให้คุณเรียงลำดับตามที่คุณต้องการ (เช่นในกรณีของคุณ@sort_order = '[CPU] DESC')
สิ่งแรกที่ฉันจะทำโดยเฉพาะอย่างยิ่งถ้านี่เป็นภารกิจที่สำคัญสำหรับทีมค้นหาและกู้ภัย - คือซื้อฮาร์ดแวร์ที่ดีกว่า คุณควรมี CPU มากขึ้นและ RAM มากขึ้นเพื่อให้บริการแอปพลิเคชันของคุณ นอกจากนี้คุณยังต้องการความพร้อมใช้งานที่สูงขึ้น (เช่นการทำคลัสเตอร์การทำมิเรอร์หรือกลุ่มความพร้อมใช้งาน) ไม่มีเหตุผลที่การรีบูตเครื่องทางกายภาพควรทำให้แอปพลิเคชันของคุณออฟไลน์โดยสมบูรณ์ - เรามีวิธีแก้ไขปัญหาที่ดีกว่า และสุดท้ายฉันก็สันนิษฐานว่า "เซิร์ฟเวอร์" นี้มีดิสก์ไดรฟ์แบบ spinny เพียงตัวเดียวเท่านั้น ซึ่งหมายความว่า I / O ทั้งหมด - จากระบบปฏิบัติการจากไฟล์ข้อมูล SQL Server, ไฟล์บันทึก, tempdb และอื่น ๆ ทั้งหมดผ่านตัวควบคุมเดียวและแบ่งปันกิจกรรมการอ่าน / เขียนบนไดรฟ์เดียว รับดิสก์เพิ่ม รับ SSD หาก / ที่ไหนที่คุณสามารถทำได้ ใช้ RAID และพยายามกระจาย I / O ออกให้ได้มากที่สุด
อย่างที่ทุกคนกล่าวว่าการขว้างฮาร์ดแวร์ที่มีปัญหาไม่ได้เป็นเพียงส่วนหนึ่งของการแก้ไข คุณต้องแยกสิ่งที่ทำให้เกิดการใช้งาน CPU มากเกินไปจากนั้นโจมตีปัญหาเหล่านั้นไม่ว่าคุณจะใช้ฮาร์ดแวร์ชนิดใด
ดูคำถาม StackOverflow นี้สำหรับแนวคิดอื่น ๆ :
/programming/945063/how-do-i-find-out-what-is-hammering-my-sql-server