เหตุใดแบบสอบถาม SQL Server จึงไม่ใช้ดิสก์ I / O มากกว่า 7MB / วินาที

ฉันมี SSD ที่ใช้การทดสอบ IOmeter แสดงประสิทธิภาพมากกว่า 200MB / s อย่างไรก็ตามเมื่อฉันเรียกใช้แบบสอบถาม SQL ใด ๆ จากเครื่องท้องถิ่นการตรวจสอบทรัพยากร windows ไม่เคยแสดงดิสก์ IO เหนือ 7MB / วินาที สิ่งนี้ถือเป็นจริงแม้กระทั่งการสืบค้นที่ใช้เวลานานกว่า 2 นาที สิ่งที่เป็นปัญหาคอขวดคือการใช้เพียง 7MB / วินาทีจาก SSD?

ฉันกำลังวิ่ง:

มาตรฐาน Windows Server 2012
SQL Server 2008 r2
Intel i7 3820
หน่วยความจำ 32GB
sandisk SSD

sql-server sql-server-2008-r2 hardware

— คณบดีเกรเกอร์
แหล่งที่มา

บางทีข้อมูลอยู่ใน RAM แล้วและไม่จำเป็นต้องเข้าถึงดิสก์

— gbn

@DeanMacGregor - คุณบริโภคผลลัพธ์อย่างไร หากอยู่ใน SSMS จะทำอย่างไรถ้าคุณลองใช้ตัวเลือกเพื่อยกเลิกผลลัพธ์ สิ่งนั้นเปลี่ยนแปลงหรือไม่? นอกจากนี้คุณอาจลองดูในsys.dm_os_waiting_tasksขณะที่แบบสอบถามกำลังทำงานเพื่อดูว่ามีประเภทรออื่น ๆ ที่กำลังเผชิญหน้าอยู่หรือไม่

— Martin Smith

คือ 200 MB / s สำหรับการเข้าถึงแบบสุ่มอ่าน (สุ่มอ่านสำหรับบล็อก 4 KB)? ฉันเดาว่านี่เป็นสิ่งที่ฐานข้อมูลมักจะทำ แบบสอบถามเขียนไปยังดิสก์ (ไฟล์ชั่วคราวชุดผลลัพธ์ชั่วคราวหรือตาราง) หรือไม่?

@DeanMacGregor - เพื่อที่จะออกจากสมการคุณสามารถกำหนดผลลัพธ์ให้กับตัวแปรสเกลาร์ (แบบสอบถามตัวอย่าง) DECLARE @Name VARCHAR(10), @High int; SELECT @Name=name, @High = high FROM master..spt_values. ดังนั้นจะไม่มีการส่งผลลัพธ์กลับไปยังลูกค้า แต่แผนและ IO จะยังคงเหมือนเดิม

— Martin Smith

สมมติว่าคุณกำลังตีความ ASYNC_NETWORK_IO รอหมายความว่าปัญหาเกี่ยวข้องกับเครือข่ายหรือไม่ มัน (โดยทั่วไป) ไม่ใช่ เป็นไปได้มากว่า @MartinSmith ได้แนะนำ (สองครั้ง) ว่า SSMS หรือแอปพลิเคชันที่คุณใช้ไม่ได้ใช้ผลลัพธ์อย่างเร็วเท่าที่ SQL กำลังแสดงผล ทำตามวิธีใดวิธีหนึ่งที่แนะนำในการละเว้นการบริโภคของแถวและคุณจะได้รับรูปภาพที่แท้จริงของปริมาณข้อมูล IO สูงสุด

— Mark Storey-Smith

จากห่วงโซ่ความคิดเห็นดูเหมือนว่าคุณกำลังASYNC_NETWORK_IOรอการแปลความหมายว่าปัญหาเกี่ยวข้องกับเครือข่าย มัน (โดยทั่วไป) ไม่ใช่

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

ในกรณีที่คุณยังไม่ได้ทำคุณจะต้องDBCC DROPCLEANBUFFERSแน่ใจว่าข้อมูลนั้นอ่านจากดิสก์มากกว่าแคชบัฟเฟอร์ ข้อสังเกตปกติของ "ในการทดสอบเท่านั้นอย่าทำสิ่งนี้ในสภาพแวดล้อมที่มีการใช้งานจริง" ฯลฯ

เพิ่มความคิดเห็นอื่น ๆ ของคุณ:

ในขณะที่ดำเนินการค้นหาที่ส่งคืนการใช้งาน CPU 9 ล้านแถวจะอยู่ที่ประมาณ 13% และ 9% ที่เป็นของ sqlserver ... มันจะไม่ส่งคืนผลลัพธ์เร็วกว่า 3 นาทีถ้าข้อมูลทั้งหมดอยู่ใน RAM หรือไม่

เราทำการทดสอบอะไรที่นี่อย่างไรและทำไม หากการค้นหา 9 ล้านแถวของคุณเป็นอย่างอื่นนอกเหนือSELECT * FROM dbo.SomeTableจากนั้นจะมีปัจจัย 1001 ที่เข้ามาเล่นนอกเหนือจากอัตราความเร็ว IO ดิบ

Intel I7-3820ของคุณเป็นโปรเซสเซอร์แบบ 4 คอร์ หากแบบสอบถามทดสอบของคุณไม่ได้สร้างแผนแบบขนานฉันจะแปลกใจถ้าคุณสามารถใช้ประโยชน์จาก CPU มากกว่า 20% จากระบบ

3 นาทีในการส่งคืน 9 ล้านแถวนั้นน่าสงสัยมากและแนะนำว่าเราไม่ได้รับภาพรวมของการทดสอบของคุณ ฉันเดาว่านี่เป็นกรณีของแผนแบบสอบถามย่อย (ไม่ขนาน) ที่อัดแน่นไปด้วยตัวดำเนินการซ้อนกันเต็มวงดึงแถวนับล้าน ๆ แถวไม่ใช่เพียงตารางเดียวSELECTเพื่อตรวจสอบปริมาณการใช้ IO

ฉันแนะนำ:

SELECT *เพื่อทดสอบเพียง IO ผ่าน SQL Server
คำถามใหม่พร้อมแผนการดำเนินการของแบบสอบถามของคุณหากคุณต้องการขุดลงไปว่าทำไมจึงไม่ทำให้ IO อิ่มตัว

— Mark Storey-Smith
แหล่งที่มา

จริงๆแล้วมันเป็นเพียงแค่เลือก * จาก dbo.sometable ขอโทษฉันไม่ได้พูดถึงว่าเร็ว สิ่งที่ฉันหมายถึงคือฉันสามารถเรียกใช้แบบสอบถามที่ปิดตารางใด ๆ ต้นกำเนิดของคำถามของฉันคือฉันสังเกตว่าดิสก์ IO ของฉันนั้นน้อยกว่าที่ฉันคาดไว้แม้จากแบบสอบถามง่ายๆ "ให้ข้อมูลมากมาย" ความกังวลหลักของฉันคือถ้าดิสก์ IO ต่ำมากอาจปรับปรุงประสิทธิภาพได้หากรูทสาเหตุของดิสก์ต่ำ IO ถูกรูทออก

— Dean MacGregor