ปริมาณการใช้“ หน่วยความจำเซิร์ฟเวอร์โดยรวม” ของ SQL Server หยุดนิ่งเป็นเดือนโดยมี 64GB + มากกว่านั้น

ฉันพบปัญหาแปลกที่ SQL Server 2016 Standard Edition 64- บิตดูเหมือนว่าได้ปิดตัวเองที่ครึ่งหนึ่งของหน่วยความจำทั้งหมดที่จัดสรรให้อย่างแม่นยำ (64GB 128GB)

ผลลัพธ์ของ@@VERSIONคือ:

Microsoft SQL Server 2016 (SP1-CU7-GDR) (KB4057119) - 13.0.4466.4 (X64) 22 ธันวาคม 2017 11:25:00 ลิขสิทธิ์ (c) Microsoft Corporation Standard Edition (64 บิต) บน Windows Server 2012 R2 Datacenter 6.3 ( รุ่น 9600:) (Hypervisor)

ผลลัพธ์ของsys.dm_os_process_memoryคือ:

เมื่อฉันแบบสอบถามsys.dm_os_performance_countersผมเห็นว่าTarget Server Memory (KB)ที่131072000และเป็นเพียงภายใต้ครึ่งหนึ่งของที่ที่Total Server Memory (KB) 65308016ในสถานการณ์ส่วนใหญ่ฉันจะเข้าใจว่านี่เป็นพฤติกรรมปกติเนื่องจาก SQL Server ยังไม่ได้กำหนดว่าจะต้องจัดสรรหน่วยความจำเพิ่มเติมสำหรับตัวเอง

อย่างไรก็ตามมันติดอยู่ที่ ~ 64GB นานกว่า 2 เดือนแล้ว ในช่วงระยะเวลานี้เราได้ทำการดำเนินการกับหน่วยความจำจำนวนมากในฐานข้อมูลบางส่วนและได้เพิ่มฐานข้อมูลเข้ากับอินสแตนซ์อีกเกือบ 40 รายการ เรานั่งที่ฐานข้อมูลทั้งหมด 292 ฐานข้อมูลแต่ละไฟล์มีการจัดสรรล่วงหน้าที่ 4GB ด้วยอัตรา 256MB autogrowth และไฟล์บันทึก 2GB พร้อมอัตรา 128MB autogrowth ฉันทำการสำรองข้อมูลเต็มรูปแบบหนึ่งครั้งทุกคืนเวลา 12:00 น. และเริ่มการสำรองข้อมูลบันทึกธุรกรรมวันจันทร์ถึงวันศุกร์เริ่มต้นที่ 6:00 น. ถึง 20:00 น. ทุก ๆ 15 นาที ฐานข้อมูลเหล่านี้ค่อนข้างต่ำในปริมาณงานโดยรวม แต่ฉันสงสัยว่ามีบางอย่างผิดปกติเนื่องจาก SQL Server ไม่ได้พุ่งไปที่Target Server Memory โดยธรรมชาติผ่านการเพิ่มฐานข้อมูลใหม่การดำเนินการค้นหาปกติรวมถึงไพพ์ไลน์ ETL ที่ใช้หน่วยความจำมาก

อินสแตนซ์ของ SQL Server นั้นกำลังนั่งอยู่บนเซิร์ฟเวอร์เสมือนของ Windows Server 2012R2 ที่มี virtualized (VMware) พร้อม CPU 12 ตัว, หน่วยความจำ 144GB (128GB ไปยัง SQL Server, 16GB ที่สงวนไว้สำหรับ Windows) และ 4 ดิสก์เสมือนทั้งหมดที่อยู่บน vSAN . Windows ตั้งอยู่บน 64GB C: ดิสก์ที่มีไฟล์เพจขนาด 32GB ไฟล์ข้อมูลนั่งอยู่บนดิสก์ 2TB D: ไฟล์บันทึกจะอยู่ด้านบนของดิสก์ 2TB L: ดิสก์และ tempdb อยู่บน 256GB T: ดิสก์ที่มีไฟล์ 8x16GB ที่ไม่มีการบันทึกอัตโนมัติ

ฉันตรวจสอบแล้วว่าไม่มีอินสแตนซ์อื่น ๆ ของ SQL Server ที่ทำงานบนเซิร์ฟเวอร์นอกเหนือจากMSSQLSERVERนี้

เซิร์ฟเวอร์นี้อุทิศให้กับอินสแตนซ์ของ SQL Server เท่านั้นดังนั้นเราจึงไม่มีแอปพลิเคชันหรือบริการอื่นที่ทำงานอยู่บนเซิร์ฟเวอร์ที่อาจใช้หน่วยความจำ

ฉันใช้ RedGate SQL Monitor เพื่อการวิเคราะห์และด้านล่างเป็นประวัติของ 18 วันที่ผ่านTotal Server Memoryมา อย่างที่คุณเห็นการใช้งานหน่วยความจำยังคงซบเซาอย่างสิ้นเชิงนอกเหนือจาก uptick เพียงครั้งเดียวที่ประมาณ 300MB ในต้นเดือนเมษายน

อะไรคือสาเหตุของสิ่งนี้ ฉันจะดูอะไรได้มากขึ้นเพื่อกำหนดว่าทำไม SQL Server ไม่ต้องการใช้หน่วยความจำ 64GB + เพิ่มเติมที่จัดสรรให้กับมัน

ผลลัพธ์ของการทำงานsp_Blitz:

sp_Blitz @OutputType = 'markdown', @CheckServerInfo = 1;

ลำดับความสำคัญที่ 50: ประสิทธิภาพการทำงาน :

• CPU Schedulers ออฟไลน์ - คอร์ CPU บางตัวไม่สามารถเข้าถึง SQL Server ได้เนื่องจากปัญหาการปิดบังหรือความเกี่ยวข้องของสิทธิ์ใช้งาน

• หน่วยความจำโหนดออฟไลน์ - เนื่องจากปัญหาการปิดบังความสัมพันธ์หรือสิทธิ์การใช้งานหน่วยความจำบางส่วนอาจไม่พร้อมใช้งาน

ลำดับความสำคัญที่ 50: ความน่าเชื่อถือ :

• Remote DAC Disabled - ไม่ได้เปิดใช้งานการเข้าถึงการเชื่อมต่อ Dedicated Admin Connection (DAC) ระยะไกล DAC สามารถแก้ไขปัญหาระยะไกลได้ง่ายขึ้นมากเมื่อ SQL Server ไม่ตอบสนอง

ลำดับความสำคัญ 100: ประสิทธิภาพ :

• มีแผนหลายแผนสำหรับหนึ่งแบบสอบถาม - 300 แผนสำหรับแบบสอบถามเดียวในแคชแผน - ซึ่งหมายความว่าเราอาจมีปัญหาเกี่ยวกับการกำหนดพารามิเตอร์

• ทริกเกอร์เซิร์ฟเวอร์เปิดใช้งาน

  • ทริกเกอร์เซิร์ฟเวอร์ [RG_SQLLighthouse_DDLTrigger] เปิดใช้งาน ตรวจสอบให้แน่ใจว่าคุณเข้าใจในสิ่งที่ทริกเกอร์กำลังทำอยู่ - ยิ่งทำงานน้อยลงเท่าไหร่ก็ยิ่งดีเท่านั้น

  • ทริกเกอร์เซิร์ฟเวอร์ [SSMSRemoteBlock] เปิดใช้งาน ตรวจสอบให้แน่ใจว่าคุณเข้าใจในสิ่งที่ทริกเกอร์กำลังทำอยู่ - ยิ่งทำงานน้อยลงเท่าไหร่ก็ยิ่งดีเท่านั้น

ลำดับความสำคัญ 150: ประสิทธิภาพ :

• แบบสอบถามบังคับให้เข้าร่วมคำแนะนำ - 1480 อินสแตนซ์ของคำใบ้การเข้าร่วมถูกบันทึกตั้งแต่เริ่มต้นใหม่ ซึ่งหมายความว่าการสืบค้นกำลังควบคุมเครื่องมือเพิ่มประสิทธิภาพ SQL Server รอบ ๆ และหากไม่ทราบว่ากำลังทำอะไรอยู่นี่อาจทำให้เกิดอันตรายมากกว่าดี สิ่งนี้สามารถอธิบายได้ว่าทำไมความพยายามปรับจูน DBA ไม่ทำงาน

• คำสั่งบังคับให้ใช้คำแนะนำการใช้งาน - อินสแตนซ์ของคำแนะนำการสั่งซื้อ 2153 ได้รับการบันทึกตั้งแต่เริ่มต้นใหม่ ซึ่งหมายความว่าการสืบค้นกำลังควบคุมเครื่องมือเพิ่มประสิทธิภาพ SQL Server รอบ ๆ และหากไม่ทราบว่ากำลังทำอะไรอยู่นี่อาจทำให้เกิดอันตรายมากกว่าดี สิ่งนี้สามารถอธิบายได้ว่าทำไมความพยายามปรับจูน DBA ไม่ทำงาน

ลำดับความสำคัญ 170: การกำหนดค่าไฟล์ :

• ฐานข้อมูลระบบบนไดรฟ์ C

  • master - ฐานข้อมูลหลักมีไฟล์ในไดรฟ์ C การวางฐานข้อมูลระบบในไดรฟ์ C ทำให้เสี่ยงต่อการหยุดทำงานของเซิร์ฟเวอร์เมื่อพื้นที่ไม่เพียงพอ

  • model - ฐานข้อมูล model มีไฟล์อยู่ในไดรฟ์ C การวางฐานข้อมูลระบบในไดรฟ์ C ทำให้เสี่ยงต่อการหยุดทำงานของเซิร์ฟเวอร์เมื่อพื้นที่ไม่เพียงพอ

  • msdb - ฐานข้อมูล msdb มีไฟล์อยู่ในไดรฟ์ C การวางฐานข้อมูลระบบในไดรฟ์ C ทำให้เสี่ยงต่อการหยุดทำงานของเซิร์ฟเวอร์เมื่อพื้นที่ไม่เพียงพอ

ลำดับความสำคัญ 200: ข้อมูล :

• ตัวแทนงานเริ่มต้นพร้อมกัน - มีการกำหนดค่างานตัวแทนของเซิร์ฟเวอร์ SQL หลายรายการให้เริ่มพร้อมกัน สำหรับรายการตารางโดยละเอียดโปรดดูที่แบบสอบถามใน URL

• ตารางในต้นแบบฐานข้อมูลหลัก - ตาราง CommandLog ในฐานข้อมูลหลักถูกสร้างขึ้นโดยผู้ใช้ปลายทางในวันที่ 30 ก.ค. 2017 5:22 PM ตารางในฐานข้อมูลหลักอาจไม่สามารถกู้คืนได้ในกรณีที่เกิดภัยพิบัติ

• TraceFlag เปิด

  • เปิดใช้งานการติดตามสถานะ 1118 ทั่วโลก

  • เปิดใช้งานการติดตามสถานะ 1222 ทั่วโลก

  • การสืบค้นกลับสถานะ 2371 ถูกเปิดใช้งานทั่วโลก

ลำดับความสำคัญ 200: การกำหนดค่าเซิร์ฟเวอร์ที่ไม่ใช่ค่าเริ่มต้น :

• Agent XP - ตัวเลือก sp_configure นี้มีการเปลี่ยนแปลง ค่าเริ่มต้นคือ 0 และได้รับการตั้งค่าเป็น 1

• backup checksum default - ตัวเลือก sp_configure นี้มีการเปลี่ยนแปลง ค่าเริ่มต้นคือ 0 และได้รับการตั้งค่าเป็น 1

• ค่าเริ่มต้นการบีบอัดข้อมูลสำรอง - ตัวเลือก sp_configure นี้มีการเปลี่ยนแปลง ค่าเริ่มต้นคือ 0 และได้รับการตั้งค่าเป็น 1

• เกณฑ์ค่าใช้จ่ายสำหรับการขนาน - ตัวเลือก sp_configure นี้มีการเปลี่ยนแปลง ค่าเริ่มต้นคือ 5 และได้รับการตั้งค่าเป็น 48

• ระดับสูงสุดของการขนาน - ตัวเลือก sp_configure นี้มีการเปลี่ยนแปลง ค่าเริ่มต้นคือ 0 และได้รับการตั้งค่าเป็น 12

• หน่วยความจำเซิร์ฟเวอร์สูงสุด (MB) - ตัวเลือก sp_configure นี้มีการเปลี่ยนแปลง ค่าเริ่มต้นคือ 2147483647 และได้รับการตั้งค่าเป็น 128000

• ปรับให้เหมาะสมสำหรับปริมาณงานเฉพาะกิจ - ตัวเลือก sp_configure นี้ได้รับการเปลี่ยนแปลง ค่าเริ่มต้นคือ 0 และได้รับการตั้งค่าเป็น 1

• แสดงตัวเลือกขั้นสูง - ตัวเลือก sp_configure นี้มีการเปลี่ยนแปลง ค่าเริ่มต้นคือ 0 และได้รับการตั้งค่าเป็น 1

• xp_cmdshell - ตัวเลือก sp_configure นี้มีการเปลี่ยนแปลง ค่าเริ่มต้นคือ 0 และได้รับการตั้งค่าเป็น 1

ลำดับความสำคัญ 200: ความน่าเชื่อถือ :

• ขั้นตอนการจัดเก็บเพิ่มเติมในปริญญาโท

• หลัก - [sqbdata] ขั้นตอนการจัดเก็บเพิ่มเติมอยู่ในฐานข้อมูลหลัก CLR อาจใช้งานอยู่และฐานข้อมูลหลักตอนนี้จำเป็นต้องเป็นส่วนหนึ่งของการวางแผนสำรอง / กู้คืนของคุณ

  • หลัก - [sqbdir] ขั้นตอนการจัดเก็บเพิ่มเติมอยู่ในฐานข้อมูลหลัก CLR อาจใช้งานอยู่และฐานข้อมูลหลักตอนนี้จำเป็นต้องเป็นส่วนหนึ่งของการวางแผนสำรอง / กู้คืนของคุณ

  • หลัก - [sqbmemory] ขั้นตอนการจัดเก็บเพิ่มเติมอยู่ในฐานข้อมูลหลัก CLR อาจใช้งานอยู่และฐานข้อมูลหลักตอนนี้จำเป็นต้องเป็นส่วนหนึ่งของการวางแผนสำรอง / กู้คืนของคุณ

  • หลัก - [sqbstatus] ขั้นตอนการจัดเก็บเพิ่มเติมอยู่ในฐานข้อมูลหลัก CLR อาจใช้งานอยู่และฐานข้อมูลหลักตอนนี้จำเป็นต้องเป็นส่วนหนึ่งของการวางแผนสำรอง / กู้คืนของคุณ

  • หลัก - [sqbtest] ขั้นตอนการจัดเก็บเพิ่มเติมอยู่ในฐานข้อมูลหลัก CLR อาจใช้งานอยู่และฐานข้อมูลหลักตอนนี้จำเป็นต้องเป็นส่วนหนึ่งของการวางแผนสำรอง / กู้คืนของคุณ

  • หลัก - [sqbtestcancel] ขั้นตอนการจัดเก็บเพิ่มเติมอยู่ในฐานข้อมูลหลัก CLR อาจใช้งานอยู่และฐานข้อมูลหลักตอนนี้จำเป็นต้องเป็นส่วนหนึ่งของการวางแผนสำรอง / กู้คืนของคุณ

  • หลัก - [sqbteststatus] ขั้นตอนการจัดเก็บเพิ่มเติมอยู่ในฐานข้อมูลหลัก CLR อาจใช้งานอยู่และฐานข้อมูลหลักตอนนี้จำเป็นต้องเป็นส่วนหนึ่งของการวางแผนสำรอง / กู้คืนของคุณ

  • หลัก - [sqbutility] ขั้นตอนการจัดเก็บเพิ่มเติมอยู่ในฐานข้อมูลหลัก CLR อาจใช้งานอยู่และฐานข้อมูลหลักตอนนี้จำเป็นต้องเป็นส่วนหนึ่งของการวางแผนสำรอง / กู้คืนของคุณ

  • หลัก - [sqlbackup] ขั้นตอนการจัดเก็บเพิ่มเติมอยู่ในฐานข้อมูลหลัก CLR อาจใช้งานอยู่และฐานข้อมูลหลักตอนนี้จำเป็นต้องเป็นส่วนหนึ่งของการวางแผนสำรอง / กู้คืนของคุณ

ลำดับความสำคัญ 210: การกำหนดค่าฐานข้อมูลที่ไม่ใช่ค่าเริ่มต้น :

• Read Committed Snapshot Isolation Enabled - การตั้งค่าฐานข้อมูลนี้ไม่ใช่ค่าเริ่มต้น

  • RedGate

  • RedGateMonitor

• Snapshot Isolation Enabled - การตั้งค่าฐานข้อมูลนี้ไม่ใช่ค่าเริ่มต้น

  • RedGate

  • RedGateMonitor

ลำดับความสำคัญ 240: รอสถิติ :

• 1 - SOS_SCHEDULER_YIELD - รอ 1770.8 ชั่วโมง, รอเฉลี่ยต่อชั่วโมง 115.9 นาที, รอสัญญาณ 100.0%, รองาน 1419212079 เวลารอเฉลี่ย 4.5 ms

ลำดับความสำคัญ 250: ข้อมูล :

• SQL Server ทำงานภายใต้บัญชี NT Service - ฉันใช้งานเป็น NT Service \ MSSQLSERVER ฉันหวังว่าฉันมีบัญชีบริการ Active Directory แทน

ลำดับความสำคัญ 250: ข้อมูลเซิร์ฟเวอร์ :

• Default Trace Contents - การติดตามเริ่มต้นเก็บข้อมูล 36 ชั่วโมงระหว่าง 14 เมษายน 2018 11:21 PM ถึง 16 เมษายน 2018 11:13 AM ไฟล์การติดตามเริ่มต้นอยู่ใน: Server \ MSSQL13.MSSQLSERVER \ MSSQL \ Log SQL Files \ Microsoft C: \ Program

• Drive C Space - 196816.00MB ฟรีบนไดรฟ์ C

• Drive D Space - 894823.00MB ฟรีบนไดรฟ์ E

• Drive L Space - 1361367.00MB ฟรีบนไดรฟ์ F

• Drive T Space - ฟรี 114441.00MB สำหรับ G drive

• ฮาร์ดแวร์ - ตัวประมวลผลเชิงตรรกะ: 12. หน่วยความจำกายภาพ: 144GB

• ฮาร์ดแวร์ - การกำหนดค่า NUMA

  • โหนด: 0 สถานะ: ออนไลน์ตัวจัดตารางเวลาออนไลน์: 4 ตัวกำหนดเวลาออฟไลน์: 2 กลุ่มตัวประมวลผล: 0 หน่วยความจำโหนด: 0 หน่วยความจำ VAS สงวนไว้ GB: 186

  • โหนด: 1 สถานะ: ออฟไลน์ตัวกำหนดเวลาออนไลน์: 0 ตัวกำหนดเวลาออฟไลน์: 6 กลุ่มตัวประมวลผล: 0 หน่วยความจำโหนด: 0 หน่วยความจำ VAS สงวนไว้ GB: 186

• การเริ่มต้นไฟล์ทันทีเปิดใช้งาน - บัญชีบริการมีสิทธิ์ดำเนินการบำรุงรักษาตามปริมาณ

• แผนการใช้พลังงาน - เซิร์ฟเวอร์ของคุณมีซีพียู 2.60GHz และอยู่ในโหมดพลังงานที่สมดุลเอ่อ ... คุณต้องการให้ซีพียูของคุณทำงานด้วยความเร็วสูงสุดใช่ไหม?

• เซิร์ฟเวอร์รีสตาร์ทครั้งล่าสุด - 9 มี.ค. 2018 7:27 AM

• ชื่อเซิร์ฟเวอร์ - [redacted]

• บริการ

  • บริการ: SQL Server (MSSQLSERVER) ทำงานภายใต้บัญชีบริการ NT Service \ MSSQLSERVER เวลาเริ่มต้นล่าสุด: 9 มีนาคม 2018 7:27 AM ประเภทเริ่มต้น: อัตโนมัติกำลังทำงานอยู่

  • บริการ: บริษัท ตัวแทนของเซิร์ฟเวอร์ SQL (MSSQLSERVER) ทำงานภายใต้บัญชีบริการ LocalSystem เวลาเริ่มต้นล่าสุด: ไม่แสดง .. ประเภทการเริ่มต้น: อัตโนมัติกำลังทำงานอยู่

• SQL Server รีสตาร์ทครั้งล่าสุด - 9 มี.ค. 2018 6:27 AM

• บริการเซิร์ฟเวอร์ SQL - รุ่น: 13.0.4466.4 ระดับแพตช์: SP1 การปรับปรุงที่สะสม: CU7 รุ่น: Standard Edition (64- บิต) กลุ่มความพร้อมใช้งาน: 0. สถานะตัวจัดการกลุ่มความพร้อมใช้งาน: 2

• เซิร์ฟเวอร์เสมือน - ประเภท: (HYPERVISOR)

• Windows Version - คุณกำลังใช้งาน Windows รุ่นที่ทันสมัย: Server 2012R2 era, 6.3

ลำดับความสำคัญ 254: Rundate :

• บันทึกของกัปตัน: ทำบางสิ่งบางอย่างและบางสิ่งบางอย่าง ...

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

ดาวน์โหลดsp_Blitz (ข้อจำกัดความรับผิดชอบ: ฉันเป็นหนึ่งในผู้เขียนสคริปต์โอเพนซอร์ซฟรีนั้น) และเรียกใช้มัน:

sp_Blitz @CheckServerInfo = 1;

ค้นหาคำเตือนเกี่ยวกับ CPU และ / หรือโหนดหน่วยความจำออฟไลน์ SQL Server Standard Edition เห็นซ็อกเก็ต CPU 4 ตัวแรกเท่านั้นและคุณอาจกำหนดค่า VM เป็นสิ่งที่คล้ายกับ CPU แบบดูอัลคอร์ 6 ตัว มันจะจบลงด้วยการกดปุ่มปัญหาคล้ายกับวิธี Enterprise Edition 20-core วงเงินฝาจำนวนหน่วยความจำที่คุณสามารถดู

หากคุณต้องการแบ่งปันผลลัพธ์ของ sp_Blitz ที่นี่คุณสามารถเรียกใช้เช่นนี้เพื่อส่งออกไปยัง Markdown ซึ่งคุณสามารถคัดลอก / วางลงในคำถามของคุณ:

sp_Blitz @OutputType = 'markdown', @CheckServerInfo = 1;

อัปเดต 2018/04/16 - ยืนยัน คุณแนบเอาต์พุต sp_Blitz (ขอบคุณสำหรับสิ่งนั้น!) และมันแสดงให้เห็นว่าคุณมี CPU และโหนดหน่วยความจำออฟไลน์ ใครก็ตามที่สร้าง VM กำหนดค่าให้เป็น 12 CPU แบบแกนเดียวดังนั้น SQL Server Standard Edition จะเห็นเพียง 4 ซ็อกเก็ตแรก (คอร์) และหน่วยความจำที่เชื่อมต่อกับพวกเขา

หากต้องการแก้ไขให้ปิด VM ตั้งค่าเป็น VM แบบ 2 ซ็อกเก็ต 6 แกนแล้ว SQL Server Standard Edition จะเห็นแกนและหน่วยความจำทั้งหมด นี่จะเป็นการลด SOS_SCHEDULER_YIELD ของคุณด้วยเช่นกัน - ตอนนี้ SQL Server ของคุณกำลังตอกย้ำ 4 คอร์แรก แต่ก็เป็นเช่นนั้น หลังจากการแก้ไขนี้จะสามารถทำงานได้กับทั้ง 12 คอร์

ในฐานะที่เป็นภาคผนวกของแผนปฏิบัติการของ Brent Ozarฉันต้องการแบ่งปันผลลัพธ์ ตามที่ Brent กล่าวไว้ภายใน VMware เราได้กำหนดค่า Virtual Machine อย่างไม่เหมาะสมกับ 12 CPU แบบ single-core สิ่งนี้ส่งผลให้ 8 คอร์ที่เหลือไม่สามารถเข้าถึงได้โดย SQL Server และทำให้เกิดปัญหาหน่วยความจำที่อธิบายในคำถามเดิมของฉัน เราวางบริการของเราในโหมดการบำรุงรักษาเมื่อคืนเพื่อกำหนดค่า VM อย่างเหมาะสม ไม่เพียง แต่เราจะเห็นหน่วยความจำคลานตามปกติ แต่เป็น Brent ยังบอกใบ้จำนวนการรอก็ลดลงชี้แจงและประสิทธิภาพโดยรวมของ SQL Server ของเราได้พุ่งสูงขึ้น การกำหนดค่า vNUMA ตอนนี้มีความสุขกับองค์ประกอบเล็ก ๆ น้อย ๆ ที่แบ่งตามภาระงานของเรา

สำหรับผู้ที่อาจใช้ประโยชน์จาก VMware vSphere 6.5 ขั้นตอนสั้น ๆ เพื่อทำรายการการกระทำที่อธิบายโดย Brent มีดังนี้

1. ล็อกอินเข้าสู่ vSphere Web Client สำหรับคลัสเตอร์ VMware ของคุณและเรียกดูไปยังเครื่องเสมือนที่โฮสต์ SQL Server VM ของคุณต้องออฟไลน์เพื่อปรับการตั้งค่า CPU และหน่วยความจำ

2. ภายในบานหน้าต่างหลักไปที่Configure > VM hardwareคลิกEditปุ่มที่มุมบนขวา Edit Settingsคุณจะเปิดเมนูบริบทที่มี สำหรับการอ้างอิงภาพด้านล่างเป็นการกำหนดค่าที่ไม่ถูกต้อง หมายเหตุที่ฉันได้ตั้งค่าให้Cores per Socket 1เมื่อพิจารณาถึงข้อ จำกัด ของ SQL Server Standard Edition นี่เป็นการกำหนดค่าที่ไม่ดี

   

3. การแก้ไขนั้นง่ายเหมือนการปรับCores per Socketค่า ในกรณีที่เราตั้งค่าให้เพื่อให้เรามี6 2 Socketsสิ่งนี้ทำให้ SQL Server สามารถใช้โปรเซสเซอร์ทั้ง 12 ตัวได้

   

หมายเหตุสำคัญ: ไม่ได้ตั้งค่าไปยังที่ที่ทั้งสองNumber of CoresหรือSocketsจะเป็นเลขคี่ NUMA รักการทรงตัวและโดยกฎง่ายๆต้องหารด้วย 2 ตัวอย่างเช่นการกำหนดค่า 4 คอร์ถึง 3 ซ็อกเก็ตจะไม่สมดุลกัน ในความเป็นจริงถ้าคุณต้องเรียกใช้sp_Blitzการกำหนดค่าประเภทนี้มันจะโยนคำเตือนเกี่ยวกับเรื่องนี้

ส่วน 3.3 ในArchitecting Microsoft SQL Server บน VMware vSphere (คำเตือน PDF) แสดงรายละเอียดนี้ แนวทางปฏิบัติที่ระบุไว้ใน whitepaper นั้นสามารถใช้ได้กับการจำลองเสมือนจริงทั้งหมดในสถานที่ของ SQL Server

ต่อไปนี้เป็นแหล่งข้อมูลเพิ่มเติมอีกเล็กน้อยที่ฉันรวบรวมจากการวิจัยหลังจากโพสต์ของเบรนต์:

• การจำลองเสมือนฐานข้อมูลขนาดใหญ่ - การวางแผนความจุของ VMware CPU

• การอนุญาตให้ใช้เครื่องเสมือน vCPU และ vNUMA - กฎของ Thumb

• การแยกคอเรซต่อซ็อกเก็ตจาก Virtual NUMA Topology ใน vSphere 6.5

ฉันจะจบการดักจับจาก RedGate SQL Monitor ตลอด 24 ชั่วโมงที่ผ่านมา จุดสำคัญของการบันทึกคือการใช้งาน CPU และจำนวนการรอ - ในช่วงชั่วโมงเร่งด่วนของเราเมื่อวานนี้เรากำลังประสบกับการใช้งาน CPU จำนวนมากและรอการขัดข้อง หลังจากการแก้ไขง่ายๆนี้เราได้ปรับปรุงประสิทธิภาพของเราเป็นสิบเท่า แม้กระทั่ง I / O ดิสก์ของเราก็ลดลงอย่างเห็นได้ชัด นี่คือการตั้งค่าที่ถูกมองข้ามอย่างง่ายดายซึ่งสามารถปรับปรุงประสิทธิภาพเสมือนโดยลำดับความสำคัญ อย่างน้อยมันก็ถูกมองข้ามโดยวิศวกรของเราและสมบูรณ์d'โอ้สักครู่

นอกจากนี้ตามMSDNมาตรฐานของ SQL Server นั้น จำกัด ที่ 64GB of RAM เรา 'แก้ไข' สิ่งนี้โดยการแยกฐานข้อมูลออกเป็นหลายอินสแตนซ์ แต่สถานการณ์ของคุณอาจไม่อนุญาต

Hmm 2016 ดูเหมือนว่าจะมีขีด จำกัด 128GB แต่ตัวแบ่งอินสแตนซ์อาจยังเป็นตัวเลือก