High Disk I / O จากเซิร์ฟเวอร์ sql หรือ High disk I / O ทำให้เซิร์ฟเวอร์ sql ช้าลงหรือไม่

ฉันโต้เถียงกับ DBA และพวกฮาร์ดแวร์สองคนเกี่ยวกับปัญหาด้านประสิทธิภาพบนเซิร์ฟเวอร์ SQL ของเรา โดยทั่วไปทุกอย่างเรียบร้อยดี แต่ในช่วงสองสามสัปดาห์ที่ผ่านมาเรามี spikes ล่าช้ามากในเซิร์ฟเวอร์ sql มันชัดเจนว่า SQL Server กำลังรอบนดิสก์ I / O แต่ฉันได้รับการบอกว่าเป็นเพราะ SQL Server จะขอ I / O สูงผิดปกติ ซึ่งไม่ใช่กรณี ฉันสามารถดูได้จากสิ่งที่กำลังทำงานอยู่ซึ่งไม่มีอะไรผิดปกติและ DBA ทุกคนใส่ใจที่จะดูว่าอะไรเป็นสาเหตุของการบล็อกและอื่น ๆ ซึ่งไม่มีประโยชน์ ตัวอย่างเช่นสิ่งสำคัญที่เราเห็นการสำรองข้อมูลคือการทำงานบนฐานข้อมูล ASPState ซึ่งเราใช้เพื่อจัดการสถานะเซสชัน ASP บนเว็บเซิร์ฟเวอร์ ปกติการดำเนินการเหล่านี้จะไม่เคยเห็นในผลลัพธ์ที่ใช้งาน Sp_who2 เนื่องจากเกิดขึ้นอย่างรวดเร็ว ฐานข้อมูลอยู่ในโหมดการกู้คืนอย่างง่ายและการบันทึกเป็นสิ่งผิดปกติ อย่างไรก็ตามในระหว่างความล่าช้าเหล่านี้เราสามารถเห็นการเลือกมากและปรับปรุงการดำเนินงานในฐานข้อมูลที่ถูกบล็อกหรือรอ ฉันแน่ใจว่าสิ่งที่เกิดขึ้นคือบางคนหรืองานบางอย่างกำลังทำงานบางอย่างที่ก่อให้เกิดการใช้งานดิสก์อย่างหนักหน่วงในอาร์เรย์การโจมตีที่ใช้สำหรับบันทึกฐานข้อมูลและไฟล์ข้อมูล ปัญหาคือการพิสูจน์เพราะไม่มีใครต้องการที่จะยอมรับว่าพวกเขากำลังทำสิ่งที่กำลังฆ่าเว็บไซต์ของเรา

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

ดูที่เคาน์เตอร์ perfmon ต่อไปนี้:

• SQL Server วัตถุตัวจัดการบัฟเฟอร์ :
  Page lookups/sec
Page reads/sec
Readahead pages/sec
• SQL Server วัตถุวิธีการเข้าถึง
  Full Scans/sec
Range Scans/sec
Skipped Ghosted Records/sec
• SQL Server, Wait Statistics Object
  Page IO latch waits

SQL Server ขับเคลื่อนการร้องขอ IO จำนวนมากจะได้รับการยืนยันพร้อมการสแกนจำนวนสูงเพิ่มการค้นหาหน้าและการอ่านหน้าและการรอ IO หน้าสูง เป็นมูลค่าลองดูsys.dm_exec_query_statsรายการที่มีการอ่านทางกายภาพสูงนับ พวกเขาสามารถระบุผู้กระทำความผิดได้อย่างรวดเร็ว

โดยทั่วไปการเข้าใกล้ปัญหาเป็นปัญหาการแก้ไขปัญหาประสิทธิภาพการทำตามวิธีการเช่นWaits and Queuesเป็นวิธีการที่เหมาะสม คุณ DBA ดูเหมือนจะทำสิ่งที่ถูกต้องดังนั้นคุณควรฟังเขา

ในการเริ่มต้นใช้แบบสอบถามการวินิจฉัยของ Glenn Berry และ Adam Machanic SP_Whoisactiveเพื่อค้นหาว่าเกิดอะไรขึ้นจริง ๆ

ครั้งแรกดูว่าไฟล์ฐานข้อมูลใดมีคอขวด IO มากที่สุดโดยเรียกใช้แบบสอบถามนี้ (แบบสอบถามโดย Glenn Berry)

SELECT  DB_NAME(fs.database_id) AS [Database Name] ,
        mf.physical_name ,
        io_stall_read_ms ,
        num_of_reads ,
        CAST(io_stall_read_ms / ( 1.0 + num_of_reads ) AS NUMERIC(10, 1)) AS [avg_read_stall_ms] ,
        io_stall_write_ms ,
        num_of_writes ,
        CAST(io_stall_write_ms / ( 1.0 + num_of_writes ) AS NUMERIC(10, 1)) AS [avg_write_stall_ms] ,
        io_stall_read_ms + io_stall_write_ms AS [io_stalls] ,
        num_of_reads + num_of_writes AS [total_io] ,
        CAST(( io_stall_read_ms + io_stall_write_ms ) / ( 1.0 + num_of_reads
                                                          + num_of_writes ) AS NUMERIC(10,
                                                              1)) AS [avg_io_stall_ms]
FROM    sys.dm_io_virtual_file_stats(NULL, NULL) AS fs
        INNER JOIN sys.master_files AS mf WITH ( NOLOCK ) ON fs.database_id = mf.database_id
                                                             AND fs.[file_id] = mf.[file_id]
ORDER BY avg_io_stall_ms DESC
OPTION  ( RECOMPILE );

จากนั้นเรียกใช้คิวรีนี้เพื่อดูเหตุการณ์สิบอันดับแรกที่เซิร์ฟเวอร์ของคุณกำลังรอ (แบบสอบถามโดยJonathan Kehayias ) คุณจะพบข้อความค้นหาที่คล้ายกันจากข้อความค้นหาการวินิจฉัยของ Glenn Berry

SELECT TOP 10
        wait_type ,
        max_wait_time_ms wait_time_ms ,
        signal_wait_time_ms ,
        wait_time_ms - signal_wait_time_ms AS resource_wait_time_ms ,
        100.0 * wait_time_ms / SUM(wait_time_ms) OVER ( ) AS percent_total_waits ,
        100.0 * signal_wait_time_ms / SUM(signal_wait_time_ms) OVER ( ) AS percent_total_signal_waits ,
        100.0 * ( wait_time_ms - signal_wait_time_ms )
        / SUM(wait_time_ms) OVER ( ) AS percent_total_resource_waits
FROM    sys.dm_os_wait_stats
WHERE   wait_time_ms > 0 -- remove zero wait_time
        AND wait_type NOT IN -- filter out additional irrelevant waits
( 'SLEEP_TASK', 'BROKER_TASK_STOP', 'BROKER_TO_FLUSH', 'SQLTRACE_BUFFER_FLUSH',
  'CLR_AUTO_EVENT', 'CLR_MANUAL_EVENT', 'LAZYWRITER_SLEEP', 'SLEEP_SYSTEMTASK',
  'SLEEP_BPOOL_FLUSH', 'BROKER_EVENTHANDLER', 'XE_DISPATCHER_WAIT',
  'FT_IFTSHC_MUTEX', 'CHECKPOINT_QUEUE', 'FT_IFTS_SCHEDULER_IDLE_WAIT',
  'BROKER_TRANSMITTER', 'FT_IFTSHC_MUTEX', 'KSOURCE_WAKEUP',
  'LAZYWRITER_SLEEP', 'LOGMGR_QUEUE', 'ONDEMAND_TASK_QUEUE',
  'REQUEST_FOR_DEADLOCK_SEARCH', 'XE_TIMER_EVENT', 'BAD_PAGE_PROCESS',
  'DBMIRROR_EVENTS_QUEUE', 'BROKER_RECEIVE_WAITFOR',
  'PREEMPTIVE_OS_GETPROCADDRESS', 'PREEMPTIVE_OS_AUTHENTICATIONOPS', 'WAITFOR',
  'DISPATCHER_QUEUE_SEMAPHORE', 'XE_DISPATCHER_JOIN', 'RESOURCE_QUEUE' )
ORDER BY wait_time_ms DESC

เมื่อคุณมีข้อมูลนี้อยู่ในมือมันจะง่ายกว่ามากในการแก้ไขปัญหา

BTW คุณสามารถค้นหาโพสต์มากมายเกี่ยวกับวิธีการใช้ sp_whoisactive สำหรับการแก้ไขปัญหาที่นี่

"ปัญหาคือการพิสูจน์ว่า" ถูกต้องกล่าวว่า ดูที่SQL Server: ลดขนาดดิสก์ I / O ให้เล็กสุด

กำลังพูดถึง DMV ต่อไปนี้

sys.dm_io_virtual_file_stats
sys.dm_io_pending_io_requests

อ้างอิง:

1. วิธีตรวจสอบเวลาแฝงของระบบย่อย IO ภายใน SQL Server
2. ประสิทธิภาพของเซิร์ฟเวอร์ SQL ของ Glenn Berry - sys.dm_io_pending_io_requests