การใช้ CPU มีผลต่อค่าใช้จ่ายของการเข้าถึง NUMA จากต่างประเทศหรือไม่

สถานการณ์

สมมติว่าฉันมีเซิร์ฟเวอร์ SQL ที่มี 4 ซ็อกเก็ตแต่ละโหนด 1 NUMA ซ็อกเก็ตแต่ละอันมี 4 คอร์ทางกายภาพ มีหน่วยความจำรวม 512 GB ดังนั้นแต่ละ NUMA node มี RAM 128 GB

ตารางคีย์ถูกโหลดลงในโหนด NUMA แรก

คำถาม

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

ฉันหวังว่าคำถามของฉันจะสมเหตุสมผล โปรดแจ้งให้เราทราบหากไม่พยายามชี้แจง

พื้นหลัง

เรามีปัญหาฐานข้อมูลในเซิร์ฟเวอร์การผลิตของเราเมื่อสัปดาห์ที่แล้วและบางส่วนของธุรกิจของเราได้รับผลกระทบมากกว่าคนอื่น ๆ เรามีข้อความค้นหาที่มีการอ่านเชิงตรรกะน้อยกว่า 1 นาที เราดูการใช้งาน CPU โดยรวมประมาณร้อยละ 60 เราไม่ได้ดูการวัดซีพียูเฉพาะซ็อกเก็ต ตัวชี้วัด I / O เป็นค่าเฉลี่ย

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

ขออภัยฉันไม่สามารถทำสิ่งนี้ให้สั้นลงได้ ...

1. Accumuated CPU ms เทียบกับตรรกะ IO
2. การจัดแนวโหนดหน่วยความจำโลจิคัลเซิร์ฟเวอร์ SQL กับโหนด NUMA จริง
3. Spinlock contention ในการจัดสรรหน่วยความจำเคียวรีพื้นที่ทำงาน
4. การมอบหมายงานให้กับตัวกำหนดเวลา
5. การจัดวางข้อมูลที่เกี่ยวข้องในบัฟเฟอร์พูล
6. การจัดวางหน่วยความจำกายภาพ

1. Accumuated CPU ms เทียบกับตรรกะ IO

   ฉันใช้กราฟของตรรกะ IO (หรือในคำศัพท์ perfmon "การค้นหาหน้าบัฟเฟอร์พูล") กับการใช้งาน CPU บ่อยครั้งมากเพื่อวัดประสิทธิภาพของซีพียูของปริมาณงานและมองหากรณีที่เกิดจาก spinlock

   แต่ SQL Server จะสะสมเวลา CPU ด้วยกิจกรรมมากมายนอกเหนือจากการค้นหาหน้าและ spinlocks:

   • มีการรวบรวมแผนและเรียบเรียงใหม่
   • รหัส CLR ถูกดำเนินการ
   • ฟังก์ชั่นจะดำเนินการ

   กิจกรรมอื่น ๆ อีกมากมายจะทำให้เวลาในการทำงานของ cpu สูงขึ้นอย่างมากโดยไม่แสดงผลในการค้นหาหน้า

   ในเวิร์กโหลดที่ฉันสังเกตเห็นหัวหน้าในกิจกรรม "ที่ไม่ใช่แบบลอจิคัล IO เข้มข้น แต่ CPU-gobbling" เหล่านี้คือการเรียงลำดับ / การแฮชกิจกรรม

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

   ข้อมูลเพิ่มเติมเกี่ยวกับหน่วยความจำพื้นที่ใช้งานและจำนวนพื้นที่ใช้งานที่อนุญาตในโพสต์เหล่านี้:

   • http://sql-sasquatch.blogspot.com/2015/08/sql-server-grantedreservedstolen_4.html

   • http://sql-sasquatch.blogspot.com/2015/08/sql-server-workspace-memory-with-twist.html

   • http://sql-sasquatch.blogspot.com/2015/03/resource-governor-to-restrict-max-query.html

2. การจัดแนวโหนดหน่วยความจำโลจิคัลเซิร์ฟเวอร์ SQL กับโหนด NUMA จริง

   SQL Server (ตั้งแต่รวมกลยุทธ์ที่รับรู้ถึง NUMA) โดยค่าเริ่มต้นจะสร้างโหนดหน่วยความจำ SQLOS สำหรับแต่ละโหนด NUMA บนเซิร์ฟเวอร์ เมื่อการจัดสรรหน่วยความจำเพิ่มขึ้นการจัดสรรแต่ละครั้งจะถูกควบคุมโดยโหนดหน่วยความจำ SQLOS อย่างใดอย่างหนึ่ง

   ในอุดมคติแล้วโหนดหน่วยความจำ SQLOS จะถูกจัดเรียงอย่างสมบูรณ์กับโหนด NUMA จริง กล่าวคือโหนดหน่วยความจำ SQLOS แต่ละโหนดมีหน่วยความจำจากโหนด NUMA เดียวโดยไม่มีโหนดหน่วยความจำ SQLOS อื่น ๆ ที่มีหน่วยความจำจากโหนด NUMA เดียวกันนั้น

   อย่างไรก็ตามสถานการณ์ในอุดมคตินั้นไม่ได้เป็นเช่นนั้นเสมอไป

   ลักษณะการโพสต์บล็อก CSS SQL Server วิศวกรต่อไปนี้ (รวมอยู่ในการตอบสนองของ Kin) ซึ่งสามารถนำไปสู่การจัดสรรหน่วยความจำโหนดข้าม NUMA สำหรับโหนดหน่วยความจำ SQLOS เมื่อสิ่งนี้เกิดขึ้นผลกระทบต่อประสิทธิภาพสามารถทำลายล้างได้

   • http://blogs.msdn.com/b/psssql/archive/2012/12/13/how-it-works-sql-server-numa-local-foreign-and-away-memory-blocks.aspx

   มีการแก้ไขเล็กน้อยสำหรับกรณีที่เจ็บปวดโดยเฉพาะอย่างยิ่งของการอ้างอิงโหนดข้าม NUMA แบบถาวร อาจเป็นคนอื่นนอกเหนือไปจากสองคนนี้เช่นกัน:

   • การแก้ไข: ปัญหาประสิทธิภาพการทำงานเกิดขึ้นในสภาพแวดล้อม NUMA ระหว่างการประมวลผลหน้าต่างประเทศใน SQL Server 2012 หรือ SQL Server 2014

   • การแก้ไข: ปัญหาประสิทธิภาพการทำงานของเซิร์ฟเวอร์ SQL ในสภาพแวดล้อม NUMA

3. Spinlock contention ในระหว่างการจัดสรรหน่วยความจำพื้นที่ใช้งาน

   นี่คือที่ที่จะเริ่มสนุก ฉันได้อธิบายไปแล้วว่าการเรียงลำดับและแฮชทำงานในหน่วยความจำของพื้นที่ใช้งาน CPU แต่ไม่ได้แสดงในหมายเลขการค้นหา bpool

   Spinlock contention เป็นอีกหนึ่งเลเยอร์ของความสนุกนี้ เมื่อหน่วยความจำถูกขโมยจากบัฟเฟอร์พูลและจัดสรรให้กับการใช้หน่วยความจำแบบสอบถามการเข้าถึงหน่วยความจำจะถูกทำให้เป็นอนุกรมด้วยสปิลล็อค โดยค่าเริ่มต้นสิ่งนี้จะเกิดขึ้นกับทรัพยากรที่แบ่งพาร์ติชันที่ระดับโหนด NUMA ดังนั้นทุกคำถามบนโหนด NUMA เดียวกันที่ใช้หน่วยความจำพื้นที่ทำงานอาจมีความขัดแย้ง Spinlock เมื่อขโมยหน่วยความจำกับทุน สิ่งที่สำคัญมากที่ควรทราบ: นี่ไม่ใช่ความเสี่ยงในการช่วงชิง "หนึ่งครั้งต่อการค้นหา" เนื่องจากเป็นช่วงเวลาของการให้สิทธิ์จริง แต่เมื่อหน่วยความจำถูกขโมยจากการให้สิทธิ์ - ดังนั้นการค้นหาด้วยการให้หน่วยความจำขนาดใหญ่มากจะมีโอกาสมากมายสำหรับการโต้เถียง spinlock ถ้าใช้สิทธิ์ส่วนใหญ่

   การติดตามค่าสถานะ 8048 ทำงานได้อย่างยอดเยี่ยมในการบรรเทาความขัดแย้งนี้โดยการแบ่งทรัพยากรเพิ่มเติมในระดับแกนกลาง

   Microsoft ระบุว่า "ให้พิจารณาการตั้งค่าสถานะการสืบค้นกลับ 8048 ถ้า 8 แกนขึ้นไปต่อซ็อกเก็ต" แต่ ... มันไม่ใช่จำนวนแกนต่อซ็อกเก็ต (ตราบใดที่มีหลายอัน) แต่จะมีโอกาสเท่าใดสำหรับการช่วงชิงงานที่ทำบนโหนด NUMA เดียว

   สำหรับโปรเซสเซอร์ AMD ที่ติดกาว (12 คอร์ต่อซ็อกเก็ต, 2 NUMA โหนดต่อซ็อกเก็ต) มี 6 คอร์ต่อโหนด NUMA ฉันเห็นระบบที่มี 4 ของซีพียูเหล่านั้น (ดังนั้นแปดโหนด NUMA, 6 คอร์แต่ละอัน) ที่ติดขัดในขบวน spinlock จนกระทั่งเปิดใช้งานการตั้งค่าสถานะการสืบค้นกลับ 8048

   ฉันได้เห็นการโต้เถียง spinlock นี้ลากลงประสิทธิภาพบน VMs ขนาดเล็กเป็น 4 vCPU การติดตามค่าสถานะ 8048 ทำในสิ่งที่ควรจะเป็นเมื่อเปิดใช้งานในระบบเหล่านั้น

   เมื่อพิจารณาว่ายังมีซีพียูที่ได้รับการปรับแต่งความถี่หลักอีก 4 ตัวด้วยปริมาณงานที่เหมาะสมพวกเขาจะได้รับประโยชน์จากการตั้งค่าสถานะการติดตาม 8048 ด้วยเช่นกัน

   CMEMTHREAD รอพร้อมกับประเภทของการโต้เถียง spinlock ที่ติดตามค่าสถานะ 8048 บรรเทา แต่คำเตือน: CMEMTHREAD รอเป็นอาการยืนยันไม่ใช่รากสาเหตุสำหรับปัญหานี้โดยเฉพาะ ฉันเคยเห็นระบบที่มี CMEMTHREAD สูง "รอเริ่มต้น" ที่การตั้งค่าสถานะการสืบค้นกลับ 8048 และ / หรือ 9024 ล่าช้าในการปรับใช้เนื่องจากเวลารอคอย CMEMTHREAD สะสมค่อนข้างต่ำ ด้วย spinlocks เวลารอคอยสะสมมักเป็นสิ่งผิดปกติที่ต้องดู แต่คุณต้องการดูเวลาที่สูญเปล่าของ CPU - แสดงโดยสปินเป็นหลักส่วนที่สองจากการรอที่เกี่ยวข้องซึ่งแสดงถึงการสลับบริบทที่ไม่จำเป็น

   • มันทำงานอย่างไร: CMemThread และดีบั๊กพวกมัน

4. การมอบหมายงานให้กับตัวกำหนดเวลา

   ในระบบ NUMA การเชื่อมต่อจะถูกกระจายไปยังโหนด NUMA (จริง ๆ แล้วเป็นกลุ่มการจัดตารางเวลา SQLOS ที่เชื่อมโยงกับพวกเขา) round-robin สมมติว่าไม่มีจุดสิ้นสุดการเชื่อมต่อที่เชื่อมโยงกับโหนด NUMA ที่เฉพาะเจาะจง หากเซสชันดำเนินการสอบถามแบบขนานจะมีการตั้งค่าที่แข็งแกร่งในการใช้งานจากโหนด NUMA เดียว อืม ... พิจารณาเซิร์ฟเวอร์โหนด 4 NUMA ที่มีข้อความค้นหาที่ซับซ้อนที่แบ่งออกเป็น 4 พา ธ และค่าเริ่มต้น 0 MAXDOP แม้ว่าเคียวรีจะใช้เธรดผู้ทำงานสูงสุด MAXDOP เท่านั้น แต่จะมีเธรดผู้ทำงาน 4 เธรดสำหรับแต่ละ CPU โลจิคัลบนโหนด NUMA แต่มี 4 เส้นทางในแผนซับซ้อน - ดังนั้น CPU แบบลอจิคัลแต่ละตัวในโหนด NUMA สามารถมีคนงานได้ 16 คน - ทั้งหมดสำหรับแบบสอบถามเดียว!

   นี่คือเหตุผลที่บางครั้งคุณจะเห็นโหนด NUMA หนึ่งโหนดทำงานหนักในขณะที่บางโหนดกำลังทำงาน

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

   ฉันพบว่าการนำ maxdop จาก 0 ไปไม่เกิน 8 จะเป็นประโยชน์ ขึ้นอยู่กับโปรไฟล์เวิร์กโหลด (ส่วนใหญ่ imo ตามจำนวนของเคียวรีที่คาดว่าอาจเกิดขึ้นพร้อมกันนาน) ไปจนถึง MAXDOP = 2 อาจรับประกัน

   การปรับเกณฑ์ต้นทุนสำหรับการขนานอาจเป็นประโยชน์เช่นกัน ระบบที่ฉันทำงานมักจะถูกบริโภคด้วยข้อความค้นหาต้นทุนสูงและไม่ค่อยพบแผนต่ำกว่า 50 หรือ 100 ดังนั้นฉันจึงมีแรงฉุดมากขึ้นโดยการปรับ maxdop (oten ที่ระดับกลุ่มเวิร์กโหลด) มากกว่าการปรับเกณฑ์ค่าใช้จ่าย

   • SQL Server PLE ที่มี 8 NUMA โหนด

     ในโพสต์นี้จะมีการกล่าวถึงการรวมกันของ spinlock รอบ ๆ หน่วยความจำพื้นที่ทำงานและการกระจายงานที่ไม่สม่ำเสมอ ดู - สิ่งเหล่านี้ล้วนสานเข้าด้วยกันจริงๆ :-)

   • SQL Server พร้อมกัน 40 แบบสอบถามแบบขนาน + (2 ซ็อกเก็ต * 10 แกนต่อซ็อกเก็ต) = ขบวนล๊อคล็อค

5. การจัดวางข้อมูลที่เกี่ยวข้องในสระ

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

   จะเกิดอะไรขึ้นถ้าตารางถูกอ่านลงใน bpool บน NUMA node 3 และหลังจากนั้นแบบสอบถามบน NUMA node 4 สแกนตารางที่ทำการค้นหา bpool ทั้งหมดที่ค้นหาผ่านโหนด NUMA

   Linchi Shea มีบทความที่ยอดเยี่ยมเกี่ยวกับผลกระทบของประสิทธิภาพนี้:

   • http://sqlblog.com/blogs/linchi_shea/archive/2012/01/30/performance-impact-the-cost-of-numa-remote-memory-access.aspx

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

   แต่ - การเข้าถึงข้ามโหนดยังนำจุดถ่ายโอนอีกจุดหนึ่งซึ่งอาจทำให้อิ่มตัว หากมีกิจกรรมมากมายที่แบนด์วิดท์หน่วยความจำระหว่างโหนด NUMA นั้นอิ่มตัวหน่วยความจำแฝงระหว่างโหนดจะเพิ่มขึ้น งานเดียวกันจะต้องใช้รอบ CPU เพิ่มเติม

   อีกครั้ง - ฉันแน่ใจว่ามีปริมาณงานที่แบนด์วิดท์หน่วยความจำคือการพิจารณาที่สำคัญ สำหรับระบบของฉันการพิจารณาอื่น ๆ ที่ฉันระบุไว้นั้นมีความสำคัญมากกว่า

6. การจัดวางหน่วยความจำกายภาพ

   อันนี้หายาก แต่เมื่อมันสำคัญมันสำคัญจริงๆ ในเซิร์ฟเวอร์ส่วนใหญ่การติดตั้งหน่วยความจำเกือบจะเป็นไปตามธรรมชาติแล้วจะสร้างความสมดุลระหว่างโหนด NUMA แต่ในบางกรณีจำเป็นต้องให้ความสนใจเป็นพิเศษสำหรับการทำให้สมดุลหน่วยความจำข้ามโหนด ประสิทธิภาพในบางระบบสามารถถูกทิ้งอย่างสมบูรณ์หากหน่วยความจำถูก slotted ในลักษณะที่ไม่สมดุล นี่คือ set-it-and-forget-it แม้ว่า ค่อนข้างหายากที่จะค้นพบปัญหาเช่นนี้หลังจากหลายเดือนของการบริการการผลิตซึ่งตรงข้ามกับหลังจากวันที่ยุ่งมาก :-)

เสร็จสิ้นที่ยิ่งใหญ่!

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

หากสถานการณ์ที่คุณสังเกตเห็นนั้นเกี่ยวข้องกับ NUMA แต่ฉันคาดหวังว่ามันจะเป็นการรวมกันของปัจจัยที่กล่าวมาข้างต้นส่วนใหญ่:

1. การใช้หน่วยความจำเวิร์กสเปซ (ซึ่งจะไม่แสดงในจำนวน IO แบบลอจิคัล)

2. ซึ่งอาจเป็นโหนดข้าม NUMA เนื่องจากสภาพหน่วยความจำต่างประเทศแบบถาวร (หากเป็นกรณีนี้ให้ค้นหาการแก้ไขที่เกี่ยวข้อง)

3. และสิ่งใดที่อาจทำให้เกิดการโต้เถียงของ spinlock ภายในโหนด NUMA ในแต่ละครั้งที่มีการจัดสรรกับการให้สิทธิ์ (แก้ไขด้วย T8048)

4. และอาจดำเนินการโดยคนงานบน CPU แบบลอจิคัลที่โอเวอร์โหลดโดยคนงานแบบสอบถามแบบขนานอื่น ๆ (ปรับ maxdop และ / หรือเกณฑ์ค่าใช้จ่ายแบบคู่ขนานตามความจำเป็น)

( โปรดอัปเดตคำถามของคุณด้วยcoreinfo -vเอาต์พุต (ยูทิลิตี sysinternal) เพื่อรับบริบทที่ดีขึ้นของ CPU / ซ็อกเก็ตและการกระจาย NUMA ของคุณ )

เราดูการใช้งาน CPU โดยรวมประมาณร้อยละ 60 เราไม่ได้ดูการวัดซีพียูเฉพาะซ็อกเก็ต ตัวชี้วัด I / O เป็นค่าเฉลี่ย

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

SELECT parent_node_id, scheduler_id, cpu_id
FROM sys.dm_os_schedulers WITH (NOLOCK) 
WHERE [status] = N'VISIBLE ONLINE';

หรือกี่NUMA:

select COUNT(distinct Parent_node_id)
from sys.dm_os_schedulers
where [STATUS] = 'VISIBLE ONLINE'
    and Parent_node_ID < 64

เรามีข้อความค้นหาที่มีการอ่านเชิงตรรกะน้อยกว่า 1 นาที

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

นอกจากนี้คุณจำเป็นต้องตั้งค่า MAXDOP เป็นค่าที่เหมาะสมมากขึ้นเพื่อความอดอยากด้ายหลีกเลี่ยงการปฏิบัติงาน

ตั้งค่าของคุณให้cost threshold of parallelismห่างจากค่าเริ่มต้น 5 เป็นค่าเริ่มต้นที่ดีเช่น 45 จากนั้นตรวจสอบค่านั้นและปรับตามสภาพแวดล้อมของคุณ

หากคุณกำลังเรียกใช้เคียวรีเฉพาะกิจจำนวนมากให้เปิด (ตั้งค่าเป็น 1) optimize for ad hoc workloadsเพื่อป้องกันการแคชในแผนแคช

ใช้ด้วยความระมัดระวัง: คุณสามารถใช้T8048ถ้าคุณกำลังเรียกใช้ SQL Server 2008/2008 R2 บนเครื่องรุ่นใหม่ที่มีมากกว่า 8 ซีพียูนำเสนอต่อ NUMA Node และมีโปรแกรมแก้ไขด่วนถ้าคุณอยู่ใน SQL Server 2012 หรือ 2014

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

อ้างอิง: มันทำงานอย่างไร: SQL Server (NUMA Local, Foreign และ Away Memory Blocks)

จากมุมมองของฮาร์ดแวร์การจัดการหน่วยความจำหลักในรูปแบบสถาปัตยกรรม Nehalem เป็นต้นไปคือการจัดการโดยคอนโทรลเลอร์หน่วยความจำแบบรวมนี่เป็นส่วน "Un-core" ของ CPU die ซึ่งแยกจากส่วนที่แกนจริงอาศัยอยู่ เนื่องจากหน่วยความจำอย่างมีประสิทธิภาพ 'สาย' สำหรับแต่ละ CPU AFAIK เข้าถึงหน่วยความจำจากต่างประเทศผ่านทางเชื่อมต่อเส้นทางด่วน (อีกครั้งจาก Nehalem เป็นต้นไป) ดังนั้นฉันจะบอกว่าความอิ่มตัวของแกน CPU ในโหนด NUMA ท้องถิ่นไม่ควรส่งผลกระทบต่อการเข้าถึงระยะไกล

คุณอาจพบว่าลิงค์นี้มีประโยชน์:

http://cs.nyu.edu/~lerner/spring10/projects/NUMA.pdf

คริส