SQL Server - ใครก็ตามที่ใช้ SUMA, ค่าสถานะการสืบค้นกลับ 8048 หรือค่าสถานะการติดตาม 8015

เมื่อเร็ว ๆ นี้รวมถึงการเริ่มต้นของ SQL Server ติดตามการตั้งค่าสถานะ 8048 เพื่อแก้ไขปัญหา contention spinlock ที่ร้ายแรงในระบบ SQL Server 2008 R2

สนใจที่จะได้ยินจากผู้อื่นที่พบกรณีการใช้งานที่ค่าประสิทธิภาพถูกส่งโดยการติดตามค่าสถานะ 8048 (เลื่อนระดับกลยุทธ์การจัดสรรหน่วยความจำแบบสอบถามจากโหนดต่อ NUMA ไปยังแกนหลัก), สถานะการติดตาม 8015 (SQL Server ละเว้นฟิสิคัล NUMA) หรือ SUMA ( มีการเข้าถึงหน่วยความจำที่สม่ำเสมอเพียงพอตัวเลือก BIOS ในเครื่อง NUMA บางเครื่อง)

ติดตามสถานะ 8048 http://blogs.msdn.com/b/psssql/archive/2011/09/01/sql-server-2008-2008-r2-on-newer-machines-with-more-than-8-cpus -presented ต่อ Numa โหนด พ.ค. จำเป็นร่องรอยธง 8048.aspx

ติดตามสถานะ 8015 http://blogs.msdn.com/b/psssql/archive/2010/04/02/how-it-works-soft-numa-io-completion-thread-lazy-writer-workers-and-memory -nodes.aspx

รายละเอียดเกี่ยวกับปริมาณงานของระบบรวบรวมตัวชี้วัดจากระบบที่มีปัญหาและรวบรวมตัวชี้วัดจากระบบหลังจากการแทรกแซงตาม

การตั้งค่าสถานะการสืบค้นกลับ 8048 เป็น 'แก้ไข' แต่แก้ไขได้ดีที่สุดหรือไม่ SQL Server จะเพิกเฉย NUMA ทางกายภาพเนื่องจากการติดตามสถานะ 8015 ได้ทำสิ่งเดียวกันหรือไม่ สิ่งที่เกี่ยวกับการตั้งค่า BIOS ให้หน่วยความจำ interleave ปล่อยให้เซิร์ฟเวอร์ที่มีพฤติกรรม SUMA เลียนแบบ SMP แทนพฤติกรรม NUMA?

ความสงบ! tw: @sql_handle

เกี่ยวกับระบบ: - Xeon E7540 @ 2.00GHz จำนวน 4 แกนไฮเปอร์เธรด - 128 GB RAM - WS2008R2 - MSSQL 2008 R2 SP2 - maxdop 6

เกี่ยวกับปริมาณงาน: - รายงานที่จัดตารางเวลา / รอคิวเป็นชุดจำนวน 1,000 ชุดขับเคลื่อนจากแอปพลิเคชันเซิร์ฟเวอร์รายงาน 2 ชุด - 3 ชุดของรสชาติ: รายวันรายสัปดาห์รายเดือน - การเชื่อมต่อเซิร์ฟเวอร์แอปพลิเคชันรายงานทั้งหมดไปยัง SQL Server ทำขึ้นเป็นบัญชีบริการเดียว - รายงานพร้อมกันสูงสุด = 90

การค้นพบที่สำคัญเกี่ยวกับระบบที่มีปัญหา: - จาก Perfmon ช่วงเวลา 15 วินาที - - ระบบยังคงอยู่ที่ 95% -100% CPU ไม่ว่าง - - การค้นหาหน้าบัฟเฟอร์ของเซิร์ฟเวอร์ SQL <10,000 ต่อ / วินาที

• จาก DMV รอและ spinlock ช่วงเวลา 5 นาที
• • บริกร CMEMTHREAD สูงและเวลารอ
• • SOS_SUSPEND_QUEUE สูงหมุนและถอยกลับ

โพสต์บล็อกของวิศวกร CSS ของ Bob Dorr บนค่าสถานะการสืบค้นกลับ 8048 บ่งชี้ว่าระบบที่มีมากกว่า 8 คอร์ต่อโหนด NUMA สามารถทำงานในอาการที่คล้ายกันเนื่องจากปัญหาคอขวดในการจัดสรรหน่วยความจำแบบสอบถาม การติดตามการตั้งค่าสถานะ 8048 จะเปลี่ยนกลยุทธ์เป็นต่อแกนแทนโหนดต่อ NUMA

การแทรกแซง

MSSQL เริ่มต้นใหม่ด้วย -T8048 ความแตกต่างเห็นได้ชัดทันที: อัตราการค้นหาหน้าบัฟเฟอร์เพิ่มขึ้นมากกว่า 1 ล้านและเพิ่มขึ้นเป็น 8 ล้านต่อวินาที ภาระงานแบตช์ที่มีปัญหาซึ่งก่อนหน้านี้ไม่สามารถเสร็จสมบูรณ์ใน 24 ชั่วโมงแล้วเสร็จในเวลาน้อยกว่า 4 ชั่วโมง ปริมาณงานชุดอื่นที่ไม่ได้มุ่งเน้นการตรวจสอบหรือการแทรกแซงถูกส่งเป็นส่วนหนึ่งของการตรวจสอบค่าการแก้ไขของการติดตามธง 8048 (และสร้างความมั่นใจว่าผลข้างเคียงที่ไม่พึงประสงค์ของมันน้อยที่สุด) ชุดรายงานนี้เสร็จสมบูรณ์ก่อนหน้านี้ใน 2 ชั่วโมง; ด้วยการตั้งค่าสถานะการติดตาม 8048 ชุดรายงานจะเสร็จสมบูรณ์ในเวลาประมาณ 20 นาที

ETL ทุกคืนก็ได้รับประโยชน์เช่นกัน เวลา ETL ลดลงจากประมาณ 60 นาทีเป็น 40 นาที

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

การเปิดช่องทางเพิ่มเติมสำหรับหน่วยความจำคิวรีให้ลบคอขวด แต่ฉันไม่แน่ใจว่าค่าใช้จ่าย การโพสต์ CSS ของ Bob Dorr ทำให้ชัดเจนว่ามีโอเวอร์เฮดหน่วยความจำเพิ่มเติมด้วยค่าสถานะการติดตาม 8048 ค่าใช้จ่ายนั้นอยู่ในขอบเขตการจัดสรรหน้าเดียวซึ่งควบคุมโดยหน่วยความจำเซิร์ฟเวอร์ MSSQL 2008 R2 สูงสุดหรือไม่ ถ้าเป็นเช่นนั้นฉันเดาว่าระบบจะมีหน้าฐานข้อมูลจำนวนน้อยลงในแคชพูลบัฟเฟอร์ ถ้าไม่ควรหน่วยความจำเซิร์ฟเวอร์สูงสุดควรลดลงเพื่อรองรับ?

นี่เป็นโพสต์ที่ยอดเยี่ยม

ในการตอบคำถามสุดท้ายของคุณฉันคาดการณ์ว่าคำตอบของคุณคือ "ใช่"

ที่กล่าวว่าฉันอาจจะมีการติดตาม Numa อ่อนก่อนที่จะหันไปใช้ธงติดตาม ฉันคิดว่าคุณพูดถูกเกี่ยวกับการจัดสรรโหนด numa และนั่นอาจเป็นสาเหตุของปัญหาของคุณ ผ่าน soft numa คุณสามารถขยายคำร้องขอได้ขึ้นอยู่กับจำนวนโหนด numa ของคุณ (4?) - ถึง 4 หากเป็นจำนวนที่ถูกต้องจากนั้นกำหนดผ่านที่อยู่ ip แต่ละโฮสต์ไปยังโหนด numa ที่เฉพาะเจาะจงเพิ่มเติม เพื่อที่ฉันจะปิดการใช้งานเธรดไฮเปอร์ เมื่อรวมกันแล้วปัญหาน่าจะลดลง แต่ก็ทำได้ด้วยค่าใช้จ่ายของตัวกำหนดเวลาที่น้อยลง

ในความคิดที่แยกจากกันฉันจะดูการกำหนดพารามิเตอร์แบบบังคับ - ความจริงที่ว่าโหลดของคุณกำลังขับ CPU ของคุณสูงมากน่าสนใจและอาจคุ้มค่าที่จะดู

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

SELECT getdate() as poll_time, node_id, node_state_desc, memory_node_id, online_scheduler_count, active_worker_count, avg_load_balance, idle_scheduler_count
FROM sys.dm_os_nodes WITH (NOLOCK) 
WHERE node_state_desc <> N'ONLINE DAC'

และ

SELECT top 10 getdate() as sample_poll, wait_type, count (*)
FROM sys.dm_os_waiting_tasks
WHERE [wait_type] NOT IN
('CLR_SEMAPHORE','LAZYWRITER_SLEEP','RESOURCE_QUEUE','SLEEP_TASK','SLEEP_SYSTEMTASK',
'SQLTRACE_BUFFER_FLUSH','WAITFOR', 'BROKER_TASK_STOP',
'BROKER_RECEIVE_WAITFOR', 'OLEDB','CLR_MANUAL_EVENT', 'CLR_AUTO_EVENT' ) 
GROUP BY wait_type
ORDER BY COUNT (*) DESC