จำเป็นต้องเข้าใจข้อผิดพลาดในการดำเนินการแบบสอบถามแบบขนาน


18

วันนี้เราประสบกับประสิทธิภาพที่ลดลงในเซิร์ฟเวอร์ sql ของเรา ทำให้เวลานี้เกิดขึ้นเราบันทึก"The query processor could not start the necessary thread resources for parallel query execution"ข้อผิดพลาดหลายครั้ง การอ่านที่ฉันทำแสดงให้เห็นว่าสิ่งนี้เกี่ยวข้องกับจำนวน CPU ที่ใช้เมื่อดำเนินการคิวรีที่ซับซ้อน CPU Utilization was only at 7%แต่เมื่อตรวจสอบในระหว่างการหยุดทำงานของเรา มีอะไรอีกบ้างที่อ้างอิงเช่นนี้ที่ฉันยังไม่ได้เจอ? นี่เป็นสาเหตุของการเสื่อมประสิทธิภาพหรือไม่หรือว่าฉันกำลังไล่ต้อนปลาเฮอริ่งแดง?

ค่า sp_configure ของฉันสำหรับสิ่งนี้มีดังนี้:

name                                minimum maximum config_value run_value
cost threshold for parallelism      0       32767   5            5

มูลค่าของmax degree of parallelismการกำหนดค่าคืออะไรและมีตัวประมวลผลกี่ตัวที่คุณมีบนเซิร์ฟเวอร์พร้อมกับการกำหนดค่า NUMA ในปัจจุบัน คุณสามารถใช้coreinfo.exeจากsysinternalsเพื่อค้นหาจำนวนโปรเซสเซอร์และการกำหนดค่า NUMA
Kin Shah

Max Parallelism ตั้งค่าเป็น 0
Lumpy

ที่อธิบายว่าทำไมเซิร์ฟเวอร์ sql จะขาดแคลนทรัพยากรเธรด
Kin Shah

@ ฉันมี 12 ตัวประมวลผล (0 - 11) ตัวประมวลผลแล้วสองตัวประมวลผลแบบลอจิคัลกับ NUMA Node แผนที่: รายการโหนด 0, โหนด 1
ก้อน

@ คินฉันคิดว่า 0 ระบุว่า SQL Server จัดการจำนวนเธรดที่ควรใช้ เหตุใดจึงส่งผลให้เซิร์ฟเวอร์ SQL ขาดทรัพยากรเธรด?
ก้อน

คำตอบ:


19

ไม่กี่เดือนที่ผ่านมาฉันประสบกับสถานการณ์ที่คล้ายกันซึ่งการตั้งค่า MAXDOP เป็นค่าเริ่มต้นและแบบสอบถามที่เรียกใช้หมดลงทำให้เธรดผู้ทำงานทั้งหมด

ในฐานะที่เป็นรีมัสชี้ให้เห็นนี้เรียกว่าคนงานอดอยากด้าย

จะมีการถ่ายโอนข้อมูลหน่วยความจำที่สร้างขึ้นบนเซิร์ฟเวอร์ของคุณเมื่อเงื่อนไขนี้เกิดขึ้น

หากคุณอยู่ที่ 2008R2 + SP1 ขึ้นไปsys.dm_server_memory_dumpsจะให้ตำแหน่งของไฟล์ดัมพ์เช่นกัน

กลับไปที่ปัญหา:

มีเธรดการตรวจสอบกำหนดการ 1 รายการต่อ NUMA โหนดและเนื่องจากคุณมี 2 NUMA โหนดจะมี 2 เธรดการตรวจสอบกำหนดการซึ่งรับผิดชอบการตรวจสอบสุขภาพของตัวจัดตารางเวลาทุก ๆ 60 วินาทีสำหรับโหนด NUMA นั้นโดยเฉพาะในขณะที่ตรวจสอบให้แน่ใจว่า ไม่.

ทุกครั้งที่มีการดึงคำของานใหม่จากคิวของตัวกำหนดตารางเวลาตัวนับกระบวนการทำงานจะเพิ่มขึ้น ดังนั้นหากตัวกำหนดตารางเวลามีคำของานอยู่ในคิวและไม่ได้ประมวลผลคำของานใด ๆ ใน 60 วินาทีตัวจัดกำหนดการจะถูกพิจารณาว่าค้างอยู่

เนื่องจากการสอบถามที่เรียกใช้ออกไปหรือการขนานอย่างกว้างขวางมีเงื่อนไขของเธรดของผู้ปฏิบัติงานเริ่มหมดเนื่องจากเธรดทั้งหมดถูกครอบครองโดยแบบสอบถามที่เรียกใช้ครั้งเดียวนั้นหรือการบล็อกเป็นเวลานานเกินไปและไม่สามารถดำเนินการใด ๆ ได้

ทางออกที่ดีที่สุดของคุณคือการปรับการตั้งค่าMax Parallelism ของคุณก่อน ค่าเริ่มต้น0 หมายถึง SQL Server สามารถใช้ CPU ที่มีอยู่ทั้งหมดสำหรับการประมวลผลแบบขนานและที่นั่นโดยการหมดเธรดผู้ปฏิบัติงานทั้งหมด

มีสาเหตุหลายประการที่อาจนำไปสู่การหมดหัวข้องาน:

  • กลุ่มการบล็อกที่มีความยาวจำนวนมากทำให้ SQL Server หมดจำนวนเธรด
  • การขนานอย่างกว้างขวางยังนำไปสู่ความอ่อนล้าของหัวข้อคนงาน
  • การรออย่างกว้างขวางสำหรับ "ล็อค" ประเภทใด ๆ - spinlocks, สลัก spinlock ที่กำพร้าเป็นตัวอย่าง

อ้างถึงคำตอบของฉันที่นี่ที่จะแสดงวิธีการคำนวณค่า MAXDOP สำหรับอินสแตนซ์เซิร์ฟเวอร์ของคุณ

นอกจากนี้ขอแนะนำให้คุณเริ่มเก็บรวบรวมข้อมูลสถิติเกี่ยวกับอินสแตนซ์เซิร์ฟเวอร์ฐานข้อมูลของคุณ


มีสิ่งใดบ้างที่บ่งบอกถึงการสืบค้นที่เรียกใช้ทันที ฉันสามารถใช้อะไรในการระบุคำค้นหาที่มีความเสี่ยง
ก้อน

แนะนำให้คุณดูที่ข้อมูลสถิติการรอเพื่อดูว่ามันเจ็บที่ไหน นอกจากนี้ดูที่sys.dm_os_schedulers-> current_tasks_count, runnable_tasks_count, current_workers_count และ active_workers_count เช่นเดียวกับsys.dm_os_wait_statsและsys.dm_os_waiting_tasks
Kin ชาห์

10

อาจมีสาเหตุหลายประการ เป็นไปได้มากว่าคุณไม่ได้ทำงาน max_worker_threadsดู เงื่อนไขนี้เรียกว่า 'การทำให้หยุดชะงักของผู้ปฏิบัติงาน' คนงานอาจถูกขโมยโดยวิธีใดวิธีหนึ่งในหลาย ๆ วิธี (ไม่มีสิ่งใดที่จะส่งผลให้มีการใช้งาน CPU สูง btw) เช่นมีคำขอจำนวนมากถูกบล็อกหรือทำสิ่งที่โง่ใน CLR (เช่นคำขอ HTTP)

อาการที่คุณเห็นเป็นเหยื่อของปัญหาไม่ใช่สาเหตุ เราไม่สามารถแนะนำวิธีแก้ปัญหาโดยไม่ทราบสาเหตุ คุณต้องรวบรวมเคาน์เตอร์ที่สมบูรณ์แบบ DMV และตรวจสอบข้อผิดพลาดสำหรับข้อมูลเพิ่มเติม


จำนวนผู้ทำงานสูงสุดถึงขั้นต่ำ = 128, สูงสุด = 32767, config = 0, รัน = 0
ก้อน

2
@Lumpy นั่นคือการกำหนดค่าสูงสุดของคุณ แต่ไม่มีที่ไหนเลยใกล้กับผู้ทำงานสูงสุดจริง เราจำเป็นต้องทราบจำนวนโปรเซสเซอร์ที่เครื่องของคุณต้องคำนวณ
Thomas Stringer
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.