SQL Server พบการร้องขอ I / O ที่ใช้เวลานานกว่า 15 วินาที

ในการผลิต SQL Server เรามีการกำหนดค่าดังต่อไปนี้:

3 เซิร์ฟเวอร์ Dell PowerEdge R630 ซึ่งรวมอยู่ในกลุ่มความพร้อมใช้งานทั้งหมด 3 เชื่อมต่อกับหน่วยเก็บข้อมูล Dell SAN เดียวซึ่งเป็นอาร์เรย์ RAID

ในบางครั้งในระดับประถมศึกษาเราเห็นข้อความคล้ายกับด้านล่าง:

SQL Server พบคำขอ I / O 11 รายการที่เกิดขึ้นในเวลานานกว่า 15 วินาทีเพื่อให้เสร็จสมบูรณ์ในไฟล์ [F: \ Data \ MyDatabase.mdf] ใน id ฐานข้อมูล 8
การจัดการไฟล์ OS คือ 0x0000000000001FBC
ออฟเซ็ตของ I / O ที่ยาวล่าสุดคือ: 0x000004295d0000
ระยะเวลาของ I / O ที่ยาวคือ: 37397 ms

เราเป็นมือใหม่ในการแก้ไขปัญหาประสิทธิภาพ

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

เรามีการตั้งค่าที่คล้ายกันและเพิ่งพบข้อความเหล่านี้ในบันทึก เราใช้ DELL Compellent SAN ต่อไปนี้เป็นสิ่งที่ควรตรวจสอบเมื่อได้รับข้อความเหล่านี้ซึ่งช่วยให้เราค้นหาวิธีแก้ไข

• ตรวจสอบเคาน์เตอร์วัดประสิทธิภาพ windows ของคุณสำหรับดิสก์ของคุณที่มีข้อความแจ้งเตือนชี้ไปที่:
  • ดิสก์เฉลี่ย อ่านเวลา
  • ดิสก์เฉลี่ย เขียนเวลา
  • ดิสก์อ่านไบต์ / วินาที
  • ดิสก์เขียนไบต์ / วินาที
  • การถ่ายโอนดิสก์ / วินาที
  • เฉลี่ย ความยาวคิวของดิสก์
• ข้างต้นเป็นค่าเฉลี่ย หากคุณมีไฟล์ฐานข้อมูลจำนวนมากในหนึ่งไดรฟ์ค่าเฉลี่ยเหล่านี้สามารถบิดเบือนผลลัพธ์และปิดบังคอขวดในไฟล์ฐานข้อมูลเฉพาะ ตรวจสอบนี้แบบสอบถามจากพอลเอส Randal ซึ่งจะส่งกลับแฝงเฉลี่ยสำหรับแต่ละไฟล์จาก sys.dm_io_virtual_file_statsDMV ในกรณีของเรารายงานเวลาในการตอบสนองเฉลี่ยเป็นที่ยอมรับ แต่ภายใต้หน้าปกเรามีไฟล์จำนวนมากที่มีเวลาแฝงเฉลี่ย> 200 ms
• ตรวจสอบเวลา มีรูปแบบใดบ้าง มันเกิดขึ้นบ่อยครั้งในเวลากลางคืนหรือไม่? ถ้าเป็นเช่นนั้นตรวจสอบว่างานการบำรุงรักษาใด ๆ ที่กำลังทำงานในเวลานั้นหรือกิจกรรมที่กำหนดไว้ซึ่งอาจเพิ่มกิจกรรมของดิสก์และเปิดเผยคอขวดในระบบย่อย IO ของคุณ
• ตรวจสอบข้อผิดพลาด Windows Event Viewer หากสวิตช์หรือ SAN ของคุณโอเวอร์โหลดหรือตั้งค่าไม่ถูกต้องสำหรับแอปพลิเคชันของคุณคุณอาจพบข้อความในบันทึกนี้และควรนำข้อมูลนี้ไปให้ผู้ดูแลระบบ SAN ของคุณ ในกรณีของเราเราได้รับข้อผิดพลาดในการเชื่อมต่อ iSCSI บ่อยครั้งตลอดทั้งวันซึ่งบ่งบอกถึงปัญหา
• ตรวจสอบรหัส SQL Server ของคุณ เมื่อคุณได้รับข้อความเหล่านี้คุณไม่ควรคิดทันทีว่ามันเป็นปัญหาของระบบย่อย IO และส่งต่อไปยังผู้ดูแลระบบ SAN ของคุณ คุณต้องทำส่วนของคุณและตรวจสอบฐานข้อมูล คุณมีคำถามที่ไม่ดีจริง ๆ ที่ถูกเรียกใช้บ่อยครั้งที่ปั่นผ่านข้อมูลมากมายหรือไม่? การจัดทำดัชนีไม่ดี? เขียนบันทึกธุรกรรมมากเกินไป? คุณสามารถใช้คิวรีโอเพนซอร์ซเพื่อตรวจสุขภาพฐานข้อมูลของคุณตัวอย่างสำหรับการตรวจสอบว่าแผนคิวรีของคุณมีลักษณะอย่างไร sp_blitzCache
• อย่าเพิกเฉยสิ่งเหล่านี้ วันนี้คุณอาจได้รับพวกเขาวันละสองสามครั้ง ... จากนั้นหลายเดือนต่อมาเมื่อปริมาณงานของคุณเพิ่มขึ้นและคุณลืมตรวจสอบพวกเขาพวกเขาเริ่มเพิ่มขึ้น การรับข้อความเหล่านี้จำนวนมากสามารถป้องกัน SQL Server จากการเข้าถึงไฟล์บางไฟล์และถ้าเป็นtempdbนั่นก็ไม่ดี ในกรณีของเรามันแย่มากที่ SQL Server ปิดตัวเองลง

วิธีแก้ปัญหาของเราคือการอัพเกรดสวิตช์เป็นสวิตช์ SAN ใช่นี่คือจุดทั้งหมดที่จะครอบคลุมใน SQL Server สิ่งที่ทำให้เราค้นพบว่าสวิตช์เป็นสิ่งที่เราได้รับข้อผิดพลาดเกี่ยวกับการตัดการเชื่อมต่อ 1,500 iSCSI pdu ในตัวแสดงเหตุการณ์แอปพลิเคชัน Windows บน SQL Server ทุกวัน นั่นทำให้การสอบสวนโดยผู้ดูแลระบบ SAN ของเราเข้าสู่สวิตช์

ทันทีหลังจากอัปเกรดข้อผิดพลาด iSCSI หายไปและเวลาแฝงเฉลี่ยลดลงเหลือประมาณ 50 มิลลิวินาทีสำหรับไฟล์ทั้งหมดและมีความสัมพันธ์กับประสิทธิภาพที่ดีขึ้นในแอปพลิเคชัน ด้วยจุดเหล่านี้ในใจหวังว่าคุณจะสามารถหาทางแก้ไขได้

นี่เป็นปัญหาของดิสก์น้อยกว่าและมักเป็นปัญหาเครือข่าย คุณรู้ไหมว่า N ใน SAN?

หากคุณไปที่ทีม SAN ของคุณและเริ่มพูดคุยเกี่ยวกับดิสก์ที่กำลังทำงานช้าพวกเขาจะแสดงกราฟแฟนซีที่มีเวลาแฝง 0 มิลลิวินาทีให้กับมันแล้วชี้ที่เย็บกระดาษให้คุณ

ให้ถามพวกเขาเกี่ยวกับเส้นทางเครือข่ายไปที่ SAN รับความเร็วหากมีหลายส่วนเป็นต้นรับตัวเลขจากพวกเขาเกี่ยวกับความเร็วที่คุณควรเห็น ถามว่าพวกเขามีมาตรฐานจากเมื่อเซิร์ฟเวอร์มีการตั้งค่า

จากนั้นคุณสามารถใช้Crystal Disk Markหรือdiskpdเพื่อตรวจสอบความเร็วเหล่านั้น หากพวกเขาไม่เข้าแถวก็เป็นไปได้มากว่าระบบเครือข่าย

คุณควรค้นหาบันทึกข้อผิดพลาดของคุณเพื่อหาข้อความที่มี "FlushCache" และ "saturation" เพราะข้อความเหล่านั้นอาจเป็นสัญญาณของความขัดแย้งของเครือข่าย

สิ่งหนึ่งที่คุณสามารถทำได้เพื่อหลีกเลี่ยงสิ่งเหล่านั้นในฐานะ DBA คือตรวจสอบให้แน่ใจว่าการบำรุงรักษาและงานที่ต้องใช้ข้อมูลจำนวนมาก (เช่น ETL) ไม่ได้เกิดขึ้นพร้อมกัน ที่สามารถกดดันเครือข่ายการจัดเก็บ

คุณอาจต้องการตรวจสอบคำตอบที่นี่สำหรับคำแนะนำเพิ่มเติม: จุดตรวจช้าและคำเตือน I / O 15 วินาทีในการจัดเก็บแฟลช

ฉัน blogged เกี่ยวกับหัวข้อที่คล้ายกันที่นี่: จากเซิร์ฟเวอร์ถึง SAN

เหตุใดจึงต้องจัดเก็บข้อมูลบน SAN ประเด็นคืออะไร? ประสิทธิภาพของฐานข้อมูลทั้งหมดนั้นเชื่อมโยงกับ Disk I / O และคุณใช้เซิร์ฟเวอร์ 3 เครื่องที่มีเพียงหนึ่งอุปกรณ์สำหรับ I / O ที่อยู่เบื้องหลัง มันไม่เข้าท่าเลย ... และน่าเสียดายมาก

ฉันใช้ชีวิตที่ต้องเผชิญกับแพลตฟอร์มฮาร์ดแวร์ที่ออกแบบมาไม่ดีซึ่งผู้คนแค่พยายามออกแบบคอมพิวเตอร์ขนาดใหญ่ พลังงานซีพียูทั้งหมดที่นี่ดิสก์ทั้งหมดที่มี ... หวังว่าจะไม่มีสิ่งนั้นเป็นแรมระยะไกล และที่แย่ที่สุดคือพวกเขาชดเชยการขาดประสิทธิภาพของการออกแบบนี้กับเซิร์ฟเวอร์ขนาดใหญ่ที่เสียค่าใช้จ่ายมากกว่าที่ควรเป็นสิบเท่า ฉันเห็น $ 400k infra ช้ากว่าแล็ปท็อป $ 1k

ซอฟต์แวร์เซิร์ฟเวอร์ SQL เป็นซอฟต์แวร์ขั้นสูงมากมันถูกออกแบบมาเพื่อใช้ประโยชน์จากฮาร์ดแวร์บิตใด ๆ , แกน CPU, CPU แคช, TLB, RAM, ตัวควบคุมดิสก์, แคชฮาร์ดไดรฟ์ ... พวกเขาเกือบจะรวมถึงระบบแฟ้มตรรกะทั้งหมด พวกเขาได้รับการพัฒนาบนคอมพิวเตอร์ปกติและมาตรฐานในระบบระดับสูง ดังนั้นเซิร์ฟเวอร์ SQL จะต้องมีดิสก์ของตัวเอง การติดตั้งบน SAN นั้นเหมือนกับ "การเลียนแบบ" คอมพิวเตอร์คุณจะสูญเสียประสิทธิภาพที่เหมาะสมทั้งหมด SAN ใช้สำหรับจัดเก็บข้อมูลสำรองไฟล์ที่ไม่เปลี่ยนรูปแบบและไฟล์ที่คุณต่อท้ายข้อมูล (บันทึก)

ผู้ดูแลระบบดาต้าเซ็นเตอร์มักจะวางทุกอย่างเท่าที่ทำได้บน SAN เพราะวิธีนี้พวกเขามีเพียงพูลเดียวที่จะจัดการมันง่ายกว่าการดูแลที่เก็บข้อมูลในแต่ละเซิร์ฟเวอร์ เป็นตัวเลือก "ฉันไม่ต้องการทำงานของฉัน" และตัวเลือกที่แย่มากเพราะพวกเขาต้องจัดการกับปัญหาด้านประสิทธิภาพและทุก บริษัท ต้องประสบกับปัญหานี้ เพียงติดตั้งซอฟต์แวร์บนฮาร์ดแวร์ที่ออกแบบมา ง่าย ๆ เข้าไว้. ดูแลแบนด์วิดท์ของ I / O แคชและค่าใช้จ่ายในการสลับบริบท, jitter ressource (เกิดขึ้นเมื่อมีการแชร์ ressource) คุณจะได้รับการบำรุงรักษา 1 / 10th ของอุปกรณ์สำหรับกำลังส่งออกดิบเดียวกันช่วยประหยัดอาการปวดหัวจำนวนมากของทีมเพิ่มประสิทธิภาพการทำงานที่ทำให้ผู้ใช้ปลายทางของคุณมีความสุขและมีประสิทธิผลมากขึ้นทำให้ บริษัท ของคุณเป็นสถานที่ทำงานที่ดีขึ้น ประหยัดพลังงานมาก (ดาวเคราะห์จะขอบคุณ)

คุณพูดในความคิดเห็นคุณกำลังพิจารณาที่จะใส่ SSD ในเซิร์ฟเวอร์ของคุณ คุณจะไม่รู้จักการตั้งค่าของคุณด้วย SSD เฉพาะเมื่อเทียบกับ SAN คุณจะได้รับการปรับปรุง 500x แม้จะมีข้อมูลและไฟล์บันทึกธุรกรรมในไดรฟ์เดียวกัน สถานะของ SQL Server ที่ทันสมัยจะมี SSD ที่แยกต่างหากอย่างรวดเร็วสำหรับข้อมูลและธุรกรรมในช่องทางควบคุมฮาร์ดแวร์ที่แตกต่างกัน (เมนบอร์ดเซิร์ฟเวอร์ส่วนใหญ่มีหลายแห่ง) แต่เมื่อเทียบกับการตั้งค่าปัจจุบันของคุณเรากำลังพูดถึง sci-fi ที่นั่น เพียงลองใช้ SSD

โอเคสำหรับทุกคนที่สนใจ

เราแก้ไขปัญหาในคำถามสองสามเดือนที่ผ่านมาเพียงแค่ติดตั้งไดรฟ์ SSD ที่แนบโดยตรงลงในแต่ละเซิร์ฟเวอร์ 3 แห่งและย้ายข้อมูลฐานข้อมูลและไฟล์บันทึกจาก SAN ไปยังไดรฟ์ SSD เหล่านั้น

สรุปเกี่ยวกับสิ่งที่ฉันได้ทำการวิจัยเกี่ยวกับปัญหานี้ (ใช้คำแนะนำจากโพสต์ทั้งหมดที่คำถามนี้) ก่อนที่เราจะตัดสินใจติดตั้งไดรฟ์ SSD:

1) เริ่มรวบรวมตัวนับ PerfMon สำหรับไดรฟ์ต่อไปนี้ที่เซิร์ฟเวอร์ทั้ง 3 ตัว:

Disk F:เป็นดิสก์แบบลอจิคัลอิง SAN มีไฟล์ข้อมูล MDF
Disk I:เป็นโลจิคัลดิสก์อ้างอิง SAN มีไฟล์บันทึก LDF
Disk T:เชื่อมต่อ SSD โดยตรงโดยเฉพาะกับ tempDB

รูปภาพด้านล่างเป็นค่าเฉลี่ยที่เก็บรวบรวมเป็นระยะเวลา 2 สัปดาห์

Disk I: (LDF)มีขนาดเล็กเช่น IO และ Latency ต่ำมากดังนั้น Disk I: สามารถถูกละเว้น
คุณจะเห็นว่าDisk T: (TempDB)มี IO ที่ใหญ่กว่าเมื่อเทียบกับDisk F: (MDF)และมันมี Latency ที่ดีขึ้นมากในเวลาเดียวกัน - 0 ms

เห็นได้ชัดว่ามีบางอย่างผิดปกติกับดิสก์ F: ที่มีไฟล์ข้อมูลอยู่มีความหน่วงแฝงสูงและคิวการเขียนดิสก์เฉลี่ยแม้จะมี IO ต่ำ

2) ตรวจสอบเวลาแฝงของแต่ละฐานข้อมูลโดยใช้แบบสอบถามจากเว็บไซต์นี้

https://www.brentozar.com/blitz/slow-storage-reads-writes/

ฐานข้อมูลที่ใช้งานอยู่ไม่กี่แห่งบนเซิร์ฟเวอร์หลักมีเวลาในการตอบสนองการอ่าน 150-250 ms และเวลาในการเขียนความล่าช้าในการเขียน 150-450 มิลลิวินาที
ไฟล์ฐานข้อมูลหลักและ msdb ที่น่าสนใจมีความล่าช้าในการอ่านสูงสุด 90 ms ซึ่งน่าสงสัย บ่งชี้อีกอย่างหนึ่งว่ามีอะไรผิดปกติกับ SAN

3) ไม่มีการกำหนดเวลาที่เฉพาะเจาะจง

ในระหว่างที่ข้อความ "SQL Server พบการเกิดขึ้น ... " ปรากฏขึ้น
ไม่มีการบำรุงรักษาหรือดิสก์หนัก ETL ทำงานเมื่อข้อความเหล่านั้นถูกบันทึกไว้

4) ตัวแสดงเหตุการณ์ของ Windows

ไม่แสดงรายการอื่น ๆ ที่จะบอกใบ้ปัญหายกเว้น "SQL Server พบการเกิดขึ้น ... "

5) เริ่มตรวจสอบคำค้นหา 10 อันดับแรก

จาก sp_BlitzCache (cpu, อ่าน, ฯลฯ ), และเว้นเมื่อเป็นไปได้
ไม่มีการสืบค้นที่หนักหน่วงอย่างยิ่ง IO ที่จะลดจำนวนข้อมูลและส่งผลกระทบต่อการจัดเก็บอย่างมากถึงแม้ว่าการ
จัดทำดัชนีในฐานข้อมูลจะใช้ได้

6) เราไม่มีทีม SAN

เรามีผู้ดูแลระบบเพียง 1 คนเท่านั้นที่ช่วยในโอกาส
เครือข่ายเส้นทางไปยัง SAN - มันเป็นแบบหลายเครือข่ายแต่ละเซิร์ฟเวอร์ 3 แห่งมีสายเคเบิลเครือข่าย 2 สายที่นำไปสู่สวิตช์แล้วไปที่ SAN และควรจะเป็น 1 กิกะไบต์ / วินาที

7) ไม่มีผลลัพธ์ CrystalDiskMark

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

8) การติดตั้งเซสชั่นขยายเหตุการณ์ในเหตุการณ์จุดตรวจสอบสำหรับฐานข้อมูลในคำถาม

เซสชัน XE ช่วยในการค้นหาว่าในระหว่างข้อความ "SQL Server พบสิ่งที่เกิดขึ้น ... " จุดตรวจสอบเกิดขึ้นช้ามาก (สูงสุด 90 วินาที)

9) บันทึกข้อผิดพลาดของเซิร์ฟเวอร์ SQL

รายการ "FlushCache" "Saturation" ที่มีอยู่สิ่ง
เหล่านี้ควรปรากฏขึ้นเมื่อเวลาจุดตรวจสอบสำหรับฐานข้อมูลที่กำหนดเกินการตั้งค่าช่วงการกู้คืน

รายละเอียดแสดงให้เห็นว่าจำนวนข้อมูลที่ด่านตรวจพยายามล้างมีขนาดเล็กและใช้เวลานานในการทำให้เสร็จสมบูรณ์และความเร็วโดยรวมประมาณ 0.25 MB / วินาที ... แปลก

10) ในที่สุดภาพนี้แสดงกราฟการแก้ไขปัญหาการจัดเก็บ:

ดูเหมือนว่าเรามี "ปัญหาฮาร์ดแวร์: - ทำงานกับผู้ดูแลระบบ / ผู้จำหน่ายฮาร์ดแวร์เพื่อแก้ไขการกำหนดค่า SAN ที่ผิดพลาด, ไดรเวอร์เก่า / ผิดพลาด, ตัวควบคุม, เฟิร์มแวร์ ฯลฯ "

ในอีกคำถาม "ด่านช้า ... " ด่านช้าและคำเตือน I / O 15 วินาทีในที่เก็บข้อมูลแฟลช ฌอนมีรายการที่ดีมากของรายการที่ต้องตรวจสอบที่ระดับฮาร์ดแวร์และซอฟต์แวร์เพื่อแก้ไขปัญหา

ดูแลระบบของเราไม่สามารถตรวจสอบทุกสิ่งจากรายการดังนั้นเราจึงเลือกที่จะโยนฮาร์ดแวร์บางอย่างที่ปัญหานี้ - มันไม่แพงเลย

ความละเอียด:

เราสั่งไดรฟ์ SSD 1 TB และติดตั้งลงในเซิร์ฟเวอร์โดยตรง

เนื่องจากเรามีกลุ่มความพร้อมใช้งานไฟล์ข้อมูลฐานข้อมูลที่ถูกย้ายจาก SAN ไปยัง SSD บนแบบจำลองรองจากนั้นจึงล้มเหลวและโอนย้ายไฟล์ในอดีตหลักสิ่งนี้อนุญาตสำหรับการหยุดทำงานทั้งหมดน้อยที่สุด - น้อยกว่า 1 นาที

ขณะนี้แต่ละเซิร์ฟเวอร์มีสำเนาข้อมูล DB ในเครื่องและทำการสำรองข้อมูลเต็ม / diff / log ไปยัง SAN ที่กล่าวถึง
ไม่มีข้อความ "SQL Server พบเหตุการณ์ ... " ในบันทึกเหตุการณ์ของ Windows Viewer Viewer และประสิทธิภาพของการสำรองข้อมูลการตรวจสอบความสมบูรณ์ การสร้างดัชนีการสืบค้น ฯลฯ เพิ่มขึ้นอย่างมาก

ประสิทธิภาพในแง่ของ IO latency มีการปรับปรุงให้ดีขึ้นมากเพียงใดเมื่อเราย้ายไฟล์ฐานข้อมูลไปยัง SSD

ในการประเมินผลกระทบประสิทธิภาพการทำงานที่ใช้ Windows Performance Monitor จะบันทึก 2 สัปดาห์ก่อนการย้ายข้อมูลและ 4 สัปดาห์หลังจากการย้ายข้อมูล:

นอกจากนี้ด้านล่างคือการเปรียบเทียบสถิติเวลาแฝงในระดับ DB (ใช้สถิติไฟล์เสมือนของ SQL Server ที่บันทึกไว้ก่อนและหลังการโยกย้าย)

สรุป

การย้ายจาก SAN ไปยัง SSD ท้องถิ่นที่ต่อพ่วงโดยตรงนั้นคุ้มค่า
มันมีผลกระทบอย่างมากต่อความหน่วงของพื้นที่จัดเก็บและปรับปรุงได้ดีกว่า 90% โดยเฉลี่ย (โดยเฉพาะการปฏิบัติการ WRITE) และเราไม่มี spikes ที่ 20-50 วินาทีที่ IO อีกต่อไป

การย้ายไปยังโลคัล SSD แก้ไขปัญหาประสิทธิภาพการจัดเก็บไม่เพียง แต่ยังรวมถึงความปลอดภัยของข้อมูลที่ฉันกังวล (ถ้า SAN ล้มเหลวเซิร์ฟเวอร์ทั้ง 3 ตัวจะสูญเสียข้อมูลในเวลาเดียวกัน)