SQL Server tempdb บนดิสก์ RAM หรือไม่

ฐานข้อมูลแอปพลิเคชันผู้ขายของเรานั้นเข้มงวดมาก TempDB

เซิร์ฟเวอร์เป็นเสมือน (VMWare) ที่มี 40 คอร์และ RAM 768GB โดยใช้ SQL 2012 Enterprise SP3

ฐานข้อมูลทั้งหมดรวมถึง TempDB อยู่ใน Tier 1 SSD ใน SAN เรามีไฟล์ข้อมูล tempdb 10 ไฟล์แต่ละไฟล์มีขนาด 1GB และมีการเติบโตอัตโนมัติ เช่นเดียวกันกับไฟล์บันทึก 70GB มีการตั้งค่าค่าสถานะการสืบค้นกลับ 1117 & 1118 แล้ว

sys.dm_io_virtual_file_stats แสดงมากกว่า 50 Terabytes อ่าน / เขียนข้อมูล tempdb & ล็อกไฟล์ในเดือนที่ผ่านมาโดยมี io_stall สะสม 250 ชั่วโมงหรือ 10 วัน

เราได้ปรับแต่งรหัสผู้ขายและ SP ในช่วง 2 ปีที่ผ่านมา

ตอนนี้เรากำลังคิดที่จะวางไฟล์ tempdb ไว้ใน RAM Drive เนื่องจากเรามีหน่วยความจำมากมาย เนื่องจาก tempdb ถูกทำลาย / สร้างใหม่เมื่อรีบูทเซิร์ฟเวอร์จึงเป็นตัวเลือกที่เหมาะสมที่สุดที่จะวางบนหน่วยความจำที่ระเหยได้ซึ่งยังถูกล้างออกเมื่อรีบูทเซิร์ฟเวอร์

ฉันได้ทดสอบสิ่งนี้ในสภาพแวดล้อมที่ต่ำลงและมันส่งผลให้เวลาในการสืบค้นเร็วขึ้น แต่เพิ่มการใช้งาน CPU เนื่องจาก CPU ทำงานได้มากขึ้นแทนที่จะต้องรอกับไดรฟ์ tempdb ที่ช้า

มีคนอื่นวาง tempdb ของพวกเขาบน RAM ในระบบการผลิตสูง oltp? มีข้อเสียที่สำคัญหรือไม่? มีผู้ค้ารายใดบ้างที่เลือกหรือหลีกเลี่ยงเป็นพิเศษ

ขั้นแรกให้แก้ไข:ตรวจสอบให้แน่ใจว่าคุณใช้งาน 2012 Service Pack 1 Cumulative Update 10 หรือใหม่กว่า ใน SQL 2014, Microsoft เปลี่ยน TempDB ให้มีความกระตือรือร้นน้อยลงในการเขียนไปยังดิสก์และพวกเขาจะทำการbackport ไปที่ 2012 SP1 CU10เพื่อให้สามารถลดแรงกดดันในการเขียนของ TempDB ได้มาก

ประการที่สองรับตัวเลขที่แน่นอนในเวลาแฝงของคุณ ตรวจสอบsys.dm_io_virtual_file_statsเพื่อดูแผงควบคุมการเขียนเฉลี่ยสำหรับไฟล์ TempDB ของคุณ วิธีที่ฉันชอบทำคือ:

sp_BlitzFirst @ExpertMode = 1, @Seconds = 30 /* Checks for 30 seconds */
sp_BlitzFirst @SinceStartup = 1 /* Shows data since startup, but includes overnights */

ดูที่ส่วนไฟล์สถิติและมุ่งเน้นไปที่การเขียนทางกายภาพ ข้อมูล SinceStartup อาจทำให้เข้าใจผิดเล็กน้อยเนื่องจากยังรวมถึงเวลาที่ CHECKDB กำลังทำงานอยู่และนั่นสามารถตอกย้ำ TempDB ของคุณได้

หากเวลาในการตอบสนองการเขียนเฉลี่ยของคุณเกิน 3 มิลลิวินาทีคุณอาจมีพื้นที่จัดเก็บข้อมูลโซลิดสเตตใน SAN แต่ก็ยังไม่เร็ว

พิจารณา SSD ท้องถิ่นสำหรับ TempDB ก่อน SSD ที่ดีในท้องถิ่น (เช่นการ์ด PCIe NVMe ของ Intel ซึ่งต่ำกว่า $ 2k USD โดยเฉพาะอย่างยิ่งในขนาดที่คุณกำลังอธิบาย) มีความหน่วงแฝงต่ำมากต่ำกว่าที่คุณสามารถทำได้ด้วยพื้นที่เก็บข้อมูลที่ใช้ร่วมกัน อย่างไรก็ตามภายใต้การจำลองเสมือนสิ่งนี้มาพร้อมกับข้อเสียเปรียบ: คุณไม่สามารถ vMotion แขกจากโฮสต์หนึ่งไปยังอีกโฮสต์หนึ่งเพื่อตอบสนองต่อการโหลดหรือปัญหาฮาร์ดแวร์

พิจารณาไดรฟ์แรมล่าสุด มีสอง gotchas ใหญ่ด้วยวิธีนี้:

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

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

การสร้างแรมไดรฟ์ควรเป็นเรื่องเล็กน้อย ธัมบ์ลินุกซ์และไดรฟ์ออปติคัลไดรฟ์ที่สามารถบูตได้หลายตัวสร้างไดรฟ์ RAM และเก็บไฟล์ระบบปฏิบัติการที่นั่น ระบบไฟล์รูทนั้นอยู่ในหน่วยความจำ ใน windows กลับมาในวันนั้นไดรฟ์ RAM ถูกโหลดเป็นไดรเวอร์อุปกรณ์ใน config.sys โดยปกติแล้วไดรเวอร์จะถูกโหลดในหน่วยความจำสูง ในความคิดของฉันนี้เป็นทางออกที่ดีและเรียบง่าย หากได้สร้างวิธีการแก้ปัญหาของคุณโดยใช้ไดรฟ์แรมฉันต้องการจะได้ยินมัน ฉันต้องการทำสิ่งที่คล้ายกัน แต่ต้องการเขียนลงในที่เก็บข้อมูลถาวรและจัดเก็บฐานข้อมูลใน RAM ในกรณีของฉันเรามีเครื่องที่สามารถติดตั้ง RAM ได้มากกว่าระบบปฏิบัติการที่สามารถใช้ได้ การสร้างดิสก์ RAM ก่อนที่โหลดระบบปฏิบัติการจะอนุญาตให้ใช้งาน RAM ระบบปฏิบัติการจะไม่เห็นเป็นอย่างอื่น