ทำไม io_stall_writes_ms สูงกว่ามากสำหรับ tempdb

เรามีไฟล์ข้อมูลผู้ใช้และระบบในดิสก์ไดรฟ์เดียวกัน (io_stall_write_ms / (1.0 + num_of_writes)) ต่ำกว่า 2 สำหรับไฟล์ผู้ใช้ แต่ไฟล์ tempdb มักจะมีมากกว่า 400 ฉันเห็นว่าในบางเซิร์ฟเวอร์และฉันอยากรู้ว่าถ้ามีเหตุผลที่ใช้เวลานานในการเขียนไปยัง tempdb กว่าไฟล์ข้อมูลฐานข้อมูลปกติ

SELECT DISTINCT UPPER(LEFT(mf.physical_name, 1)) AS Directory,
( io_stall_write_ms / ( 1.0 + num_of_writes ) ) as result, 
io_stall_write_ms, num_of_writes, 
fs.database_id, 
fs.[file_id]
FROM sys.dm_io_virtual_file_stats(NULL, NULL) AS fs
INNER JOIN sys.master_files AS mf ON fs.database_id = mf.database_id
AND fs.[file_id] = mf.[file_id]

ขอบคุณ,

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

การอภิปราย / คำตอบที่นานขึ้น:

มีสองคำถามที่เล่นอยู่ที่นี่ -

1. ) ฉันจะทำอย่างไรเมื่อฉันเห็นแผงลอย IO สูง

ก่อนอื่น "สูง" อยู่ในสายตาของคนดู หากคุณถาม 10 DBA ว่า "สูงเกินไป" สำหรับ IO แผงลอยคุณอาจได้รับคำตอบที่แตกต่างกัน 2-3 ข้อกับตัวเลขในนั้น 5-6 "มันขึ้นอยู่กับ" คำตอบและจ้องเปล่าหนึ่งอัน ข้อสันนิษฐานของฉันคือค่าเฉลี่ย 400ms อาจสูงเกินไปที่นี่โดยเฉพาะเมื่อฐานข้อมูลอื่น ๆ อยู่ที่ 2 มิลลิวินาทีหรือต่ำกว่าสำหรับช่วงเวลาเฉลี่ย

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

แต่เมื่อฉันสงสัยว่าฉันมีปัญหาเกี่ยวกับประสิทธิภาพของดิสก์หรือเห็นบางสิ่งบางอย่างในแบบสอบถามเช่นนี้ฉันมักทำตามกระบวนการที่มีลักษณะดังนี้:

1. ดูสถิติการรอบนเซิร์ฟเวอร์ @swasheck แบ่งปันลิงก์ที่ดีเยี่ยมเป็นความคิดเห็นในคำตอบด้านล่าง สิ่งนี้จะนำคุณไปสู่โพสต์ของ Paul Randal เกี่ยวกับการดูและวิเคราะห์สถิติการรอใน SQL Server ไปที่นั่น. คุณกำลังรอคอยอะไรอยู่ คุณเห็นรอที่เกี่ยวข้องกับประสิทธิภาพ IO ( PAGEIOLATCH_*, IO_COMPLETION, WRITELOGฯลฯ ?) หากคุณทำสิ่งนี้เป็นสิ่งบ่งชี้อีกอย่างหนึ่งว่าคุณมีปัญหาเกี่ยวกับประสิทธิภาพของ IO เช่นเดียวกับแผงลอย IO แต่มันให้ข้อตกลงแบบอื่นกับคุณที่นี่
2. ดูประสิทธิภาพของ IO โดยเฉพาะอย่างยิ่งมองเข้าไปใน perfmon ที่Physical Disk:Avg Disk Sec/ReadและAvg Sec Disk Sec/Writeเคาน์เตอร์ วัดความล่าช้าของคุณ ดูตัวนับเหล่านี้ในช่วงเวลาที่บันทึกไว้ในไฟล์บันทึกประสิทธิภาพ คุณเห็นอะไรโดยเฉลี่ย หากคุณเห็นตัวเลขในช่วง 0.020 วินาที (20ms) อาจเป็นปัญหาได้ หากคุณเห็นตัวเลขมากกว่า 40-50ms เฉลี่ยหรือสูงกว่าจะเป็นการบ่งชี้ปัญหาได้มากขึ้น ดูที่แหลมของคุณหรือไม่ พวกเขาไปสูงแค่ไหนและนานเท่าไหร่ ถ้าคุณเห็น spikes ลงในร้อย ms และพวกมันมีอายุการใช้งานสิบหรือคะแนนวินาทีหรือมากกว่าและ / หรือเกิดขึ้นบ่อยครั้งคุณมีแนวโน้มที่จะมีปัญหากับประสิทธิภาพการทำงาน IO ของคุณสำหรับภาระงานของคุณ
3. ดูการตั้งค่า IO ของคุณ มันคืออะไร? ดิสก์ท้องถิ่น SAN? พื้นที่เก็บข้อมูล? คุณควรเห็นอะไรแบบนี้ตลอดและ IOPs? มันเพียงพอสำหรับสิ่งที่คุณพยายามทำหรือไม่? คุณอาจลดขนาด IO ลงไปสำหรับภาระงานของคุณ อย่าเพียงแค่ดูที่แกนหมุนจริงการตั้งค่า RAID ฯลฯ ดูเส้นทางของคุณไปยังดิสก์ของคุณ คุณผลักดันทุกอย่างผ่านลิงก์ 1GB เดียวที่คุณแบ่งปันด้วยการรับส่งข้อมูลจำนวนมากหรือไม่? คุณสามารถดูการวัดประสิทธิภาพดิสก์จากมุมมองของที่เก็บข้อมูลได้หรือไม่

( หมายเหตุ:สำหรับการวิเคราะห์สถิติการรอและการวิเคราะห์ perfmon - ดูช่วงเวลาและประเภทการใช้งานต่าง ๆ คุณมีสถิติการใช้งานในเวลากลางคืนแตกต่างจากตอนกลางวันหรือไม่หน้าต่างประมวลผลแบบแบตช์หน้าต่างบำรุงรักษาที่คุณสร้างดัชนีจำนวนมาก ดูเครื่องมือเหล่านี้ในแต่ละช่วงเวลาและทำความเข้าใจกับสิ่งที่คุณเห็นในแต่ละครั้ง)

การพิจารณาประสิทธิภาพของ IO อื่นที่นี่ -

• คุณบอกว่าระบบฐานข้อมูลและฐานข้อมูลผู้ใช้ร่วมกัน ผลิตนี้หรือไม่? ถ้าเป็นเช่นนั้นนั่นอาจไม่ใช่สถานการณ์ที่ดีที่สุดเสมอไป คุณยังแชร์ไฟล์บันทึกและไฟล์ข้อมูลในไดรฟ์เดียวกันหรือไม่ นั่นไม่ใช่สถานการณ์ที่ดีที่สุดเช่นกัน มีอะไรอื่นที่ใช้ร่วมกันพื้นที่เก็บข้อมูลนี้? ในโลกที่คุณกังวลเกี่ยวกับแกนหมุนและกลุ่มการจู่โจมและดิสก์และต้องตัดสินใจว่าใครจะได้ดิสก์ที่มีประสิทธิภาพดีที่สุดฉันมักจะ (ตามกฎทั่วไปของหัวแม่มือ .. ซึ่งไม่ค่อยดีในโลก DB แต่อันนี้มีแนวโน้มที่จะถือเป็นจริง) ไปกับฉันที่เร็วที่สุดและทุ่มเทให้กับ TempDB (เพิ่มเติมในด้านล่าง) จากนั้นตามด้วยไฟล์บันทึกแล้วไฟล์ข้อมูล ในโลกที่คุณมีดิสก์จำนวนมากบนอุปกรณ์เช่น NetApp, Dell Equal Logic หรือ EMC VNX เป็นต้นคุณไม่ต้อง '

2. ) อะไรคือสาเหตุบางอย่างของ TempDB อาจสูงกว่านี้?

ดังนั้น TempDB เป็นฐานข้อมูลและสามารถมี IO แผงลอยเหมือนฐานข้อมูลอื่น ๆ ที่ฉันเพิ่งกล่าวถึง แต่อะไรคือสาเหตุที่ทำให้เทมเพลท TempDB มีการอ่านที่สูงกว่า (ไม่ละเอียดถี่ถ้วนฉันยินดีเพิ่มเติมหรือความคิดในการแก้ไขคำตอบหรือความคิดเห็นอื่น ๆ ) -

1. เนื่องจากรหัสของคุณ - คุณใช้ TempDB มากในรหัสของคุณหรือไม่ มีการสร้างและทำลายตาราง temp และตัวแปรของตารางจำนวนมากหรือไม่ ทำสิ่งต่าง ๆ มากมายใน TempDB เช่นนี้? ไม่ดีหรือไม่ดี แต่คุณอาจดูและเข้าใจรูปแบบการใช้ TempDB ของคุณโดยเจตนา
2. TempDB เป็น workhorse ที่ใช้ร่วมกัน - TempDB เป็นฐานข้อมูลหนึ่งที่ใช้เป็นพื้นที่ชั่วคราวสำหรับวัตถุชั่วคราวที่ผู้ใช้กำหนดและตารางงานและการดำเนินงานต่างๆที่ใช้โดยอินสแตนซ์ SQL ทั้งหมดของคุณ มีฐานข้อมูลผู้ใช้กี่คน ภาระงานประเภทใดที่คุณเห็นโดยทั่วไป TempDB เป็นแหล่งข้อมูลเดียวสำหรับทุกสิ่งที่จะแบ่งปัน
3. คิวรีที่ไม่มีประสิทธิภาพและหน่วยความจำไม่เพียงพอ - อาจมีคิวรีที่ไม่ได้ใช้ดัชนีอย่างแน่นหนาเพียงพอหรือกำลังทำการสแกนและเรียงลำดับขนาดใหญ่ การดำเนินการแฮชขนาดใหญ่และหน่วยความจำบนเซิร์ฟเวอร์ไม่เพียงพอสำหรับสิ่งเหล่านี้ การดำเนินการเหล่านี้จะ "กระเด็น" ไปยัง TempDB เป็นโต๊ะทำงานเบื้องหลัง บางครั้งสิ่งนี้สามารถหลีกเลี่ยงได้โดยดูที่แผนคิวรีของคุณและการจัดทำดัชนีหรือปรับแต่งแบบสอบถาม บางครั้งมันเกิดขึ้น (มากขึ้นตามปริมาณงานคลังสินค้าฉันพบ) หากคุณมีหน่วยความจำเพียงพอสิ่งนี้สามารถช่วยได้ แต่แบบสอบถามเหล่านี้ยังสามารถรั่วไหลได้ตลอดเวลา ดูแบบนี้เช่นกัน
4. คุณกำลังใช้ระดับการอ่านข้อมูลสแนปช็อตที่แยกต่างหากพร้อมจำนวนอัปเดตที่เหมาะสมในระบบของคุณหรือไม่ สิ่งนี้ยังสามารถส่งผลให้กิจกรรม TempDB เพิ่มขึ้น

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

TempDB ใช้ร่วมกันระหว่างฐานข้อมูลทั้งหมดในอินสแตนซ์ ดังนั้นจึงมีบางครั้งอาจเป็นความขัดแย้งภายใน TempDB สำหรับบางหน้า: SGAM , GAMและPFS สรุปหน้าเหล่านี้ติดตามสิ่งที่ถูกใช้ใน TempDB จนถึงขณะนี้และที่ว่างสำหรับการใช้ใหม่

โดยทั่วไปจะมีการจัดการโดยการเพิ่มไฟล์ข้อมูลหลายไฟล์ไปยัง TempDB มีปรัชญาแตกต่างกันเล็กน้อยตามจำนวนที่ถูกต้อง แต่ทั้งหมดเห็นด้วยคุณควรมีมากกว่าหนึ่ง

ต่อไปนี้เป็นข้อซักถามบางข้อสำหรับเรียกใช้ ...

อันนี้จะแสดงให้คุณเห็นว่ามีไฟล์กี่ไฟล์ TempDB และอยู่ที่ใด

-- tempdb layout
use tempdb
go
exec sp_helpfile
go

อันนี้จะแสดงจำนวนซีพียูและคอร์ที่คุณมี

-- cores and hyperthreading
select cpu_count, hyperthread_ratio 
from sys.dm_os_sys_info
go

อันนี้จะแสดงจำนวนโหนดและคอร์จำนวน NUMA รายการต่อ NUMA โหนดที่คุณมี

-- numa nodes and schedulers
select node_id, online_scheduler_count
from sys.dm_os_nodes
order by node_id
go

อันนี้จะแสดงให้คุณเห็นว่าหน้าใดที่กำลังรออยู่ใน TempDB

-- see if anything is waiting on tempdb
select * 
from sys.dm_os_waiting_tasks
where resource_description like '2:%'
go

ต่อไปนี้เป็นบทความที่ให้รายละเอียดเพิ่มเติมเกี่ยวกับปัญหาการช่วงชิงหน้า

ตกลงดังนั้นตอนนี้ส่วนปรัชญา ... :-)

สำหรับตัวเองถ้าฉันบนSMPระบบฉันเพียงต้องการให้เป็นไฟล์จำนวนมากเป็นครึ่งหนึ่งของแกนทั้งหมด

ถ้าฉันบนNUMAระบบแล้วฉันเพียงต้องการให้เป็นไฟล์จำนวนมากเป็นแกนต่อ NUMA โหนด

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

หากฉันยังพบปัญหาอยู่ฉันจะเพิ่มอีกสองคน ตรวจสอบอีกครั้งเพิ่มมากขึ้นและทำซ้ำจนกว่าความขัดแย้งจะหายไป