G / Ç istekleri 15 saniyeden uzun sürüyor

Genellikle haftalık tam yedeklemelerimiz yaklaşık 35 dakika içinde tamamlanır; günlük fark yedekleme işlemleri ~ 5 dakika içinde tamamlanır. Salı gününden bu yana günlüklerin tamamlanması yaklaşık 4 saat sürdü, gereğinden fazla olması gerekiyor. Tesadüfen, bu yeni bir SAN / disk yapılandırması yaptıktan hemen sonra gerçekleşmeye başladı.

Sunucunun üretimde çalıştığını ve genel bir sorunumuz olmadığını, sorunsuz bir şekilde çalıştığını unutmayın - öncelikle yedekleme performansında kendini gösteren GÇ sorunu hariç.

Yedekleme sırasındaki dm_exec_requests dosyasına bakıldığında, yedekleme sürekli olarak ASYNC_IO_COMPLETION bekliyor. Aha, bu yüzden disk çekişme var!

Bununla birlikte, ne MDF (günlükler yerel diskte depolanır) ne de yedek sürücü herhangi bir etkinliğe sahip değildir (IOPS ~ = 0 - çok fazla belleğimiz var). Disk sırası uzunluğu ~ = 0 da. İşlemci% 2-3 civarında bir orana ulaştı, sorun yok.

SAN, 6x10k SAS sürücülerden oluşan LUN bir Dell MD3220i'dir. Sunucu SAN'a iki fiziksel yoldan bağlanır, her biri SAN'a yedekli bağlantılara sahip ayrı bir anahtardan geçer - ikisi herhangi bir zamanda etkin olan toplam dört yoldur. Her iki bağlantının da görev yöneticisi aracılığıyla etkin olduğunu doğrulayabilirim - yükü eşit şekilde bölerek. Her iki bağlantı da 1G tam çift yönlü çalışıyor.

Jumbo frame'leri kullanırdık, ancak burada herhangi bir sorunu ellerinden almalarını engelledim - değişiklik yok. Başka LUN'lara bağlı başka bir sunucumuz (aynı OS + config, 2008 R2) var ve hiçbir sorun göstermiyor. Ancak, SQL Server çalıştırmıyor, sadece CIFS'i paylaşıyor. Bununla birlikte, LUN'larından tercih edilen yollarından biri, sorunlu LUN'larla aynı SAN denetleyicisinde - bu yüzden bunu da ekledim.

Birkaç SQLIO testi yapmak (10G test dosyası), sorunlara rağmen IO'nun iyi olduğunu gösteriyor gibi görünüyor:

sqlio -kR -t8 -o8 -s30 -frandom -b8 -BN -LS -Fparam.txt
IOs/sec:  3582.20
MBs/sec:    27.98
Min_Latency(ms): 0
Avg_Latency(ms): 3
Max_Latency(ms): 98
histogram:
ms: 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+
%: 45  9  5  4  4  4  4  4  4  3  2  2  1  1  1  1  1  1  1  0  0  0  0  0  2

sqlio -kW -t8 -o8 -s30 -frandom -b8 -BN -LS -Fparam.txt
IOs/sec:  4742.16
MBs/sec:    37.04
Min_Latency(ms): 0
Avg_Latency(ms): 2
Max_Latency(ms): 880
histogram:
ms: 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+
%: 46 33  2  2  2  2  2  2  2  1  1  1  1  0  0  0  0  0  0  0  0  0  0  0  1

sqlio -kR -t8 -o8 -s30 -fsequential -b64 -BN -LS -Fparam.txt
IOs/sec:  1824.60
MBs/sec:   114.03
Min_Latency(ms): 0
Avg_Latency(ms): 8
Max_Latency(ms): 421
histogram:
ms: 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+
%:  1  3 14  4 14 43  4  2  1  1  1  1  1  1  0  0  0  0  0  0  0  0  0  0  6

sqlio -kW -t8 -o8 -s30 -fsequential -b64 -BN -LS -Fparam.txt
IOs/sec:  3238.88
MBs/sec:   202.43
Min_Latency(ms): 1
Avg_Latency(ms): 4
Max_Latency(ms): 62
histogram:
ms: 0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+
%:  0  0  0  9 51 31  6  1  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0  0

Bunların hiçbir şekilde ayrıntılı testler olmadığının farkındayım, ancak bunun tam bir çöp olmadığını bilmek beni rahatlatıyor. Yüksek yazma performansının iki aktif MPIO yolundan kaynaklandığını unutmayın; bununla birlikte okuma yalnızca bunlardan birini kullanır.

Uygulama olay günlüğünü kontrol etmek, etrafa dağılmış olanlar gibi olayları ortaya çıkarır:

SQL Server has encountered 2 occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [J:\XXX.mdf] in database [XXX] (150).  The OS file handle is 0x0000000000003294.  The offset of the latest long I/O is: 0x00000033da0000

Sabit değiller, ancak düzenli olarak oluyorlar (saatte birkaç, yedekleme sırasında daha fazla). Bu olayla birlikte, Sistem olay günlüğü şunları gönderir:

Initiator sent a task management command to reset the target. The target name is given in the dump data.
Target did not respond in time for a SCSI request. The CDB is given in the dump data.

Bunlar aynı SAN / Denetleyicide çalışan ve sorunlu olmayan CIFS sunucusunda da meydana geliyor ve Googling'imden kritik öneme sahip değiller.

Tüm sunucuların, güncel sürücülerle aynı NIC - Broadcom 5709C’leri kullandığını unutmayın. Sunucuların kendisi Dell R610's.

Daha sonra ne kontrol edeceğime emin değilim. Baska öneri?

Güncelleme - Çalışan perfmon
Ort. Yedekleme yaparken disk sn / Okuma ve Yazma perf sayaçları. Yedekleme cayır cayır yanmaya başlar ve daha sonra% 50'de yavaşça% 100'e doğru sürünerek ölü durur, ancak olması gereken sürenin 20 katıdır.

Kullanılan her iki SAN yolunu ve ardından bırakmayı gösterir.

Yedekleme 15:38:50 civarında başladı - hepsinin iyi göründüğünü farkettikten sonra bir dizi tepe noktası var. Yazma ile ilgilenmiyorum, sadece okuyor gibi görünüyor.

Çok az hareket açık / kapalı olmasına dikkat edin, ancak en uçunda yanıcı performans var.

Ortalama bir genel olmasına rağmen, maksimum 12sn değerine dikkat edin.

Güncelleme - NUL cihazına yedekleme
Okuma sorunlarını izole etmek ve işleri basitleştirmek için aşağıdakileri çalıştırdım:

BACKUP DATABASE XXX TO DISK = 'NUL'

Sonuçlar tam olarak aynıydı - bir patlama okumasıyla başlıyor ve sonra şimdi ve sonra operasyonları sürdürerek durur:

Güncelleme - IO durakları Shawn tarafından tavsiye edildiği gibi
dm_io_virtual_file_stats sorgusunu Jonathan Kehayias ve Ted Kruegers kitabından (sayfa 29) çalıştırdım. En iyi 25 dosyaya bakılırsa (her biri birer veri dosyası - tüm sonuçlar veri dosyasıdır), okunanların yazmadan daha kötü olduğu anlaşılıyor - belki de yazanlar doğrudan SAN önbelleğine gider, ancak soğuk okumaların diske basması gerekir - sanırım .

Güncelleme - Bekleme istatistikleri Bekleme istatistikleri
toplamak için üç test yaptım. Bekleme istatistikleri Glenn Berry / Paul Randals betiği kullanılarak sorgulandı . Ve sadece onaylamak için - yedekler kaset için değil, bir iSCSI LUN'a yapılıyor. NUL yedeklemesine benzer sonuçlarla, yerel diske yapılan sonuçlar benzerdir.

Silinen istatistikler 10 dakika koştum, normal yük:

Silinen istatistikler 10 dakika koştum, normal yük + normal yedekleme çalışması (tamamlanmadı):

Silinen istatistikler 10 dakika koştum, normal yük + NUL yedekleme çalışıyor (tamamlanmadı):

Güncelleme - Wtf, Broadcom?
Mark Storey-Smiths'in önerileri ve Kyle Brandts’in Broadcom NIC’lerle önceki deneyimlerine dayanarak, bazı deneyler yapmaya karar verdim. Birden fazla aktif yolumuz olduğu için, herhangi bir kesinti yaratmadan NIC'lerin konfigürasyonunu birer birer kolayca değiştirebilirim.

TOE ve Büyük Gönderme Boşaltma işlevinin devre dışı bırakılması, neredeyse mükemmel bir çalışma sağladı:

Processed 1064672 pages for database 'XXX', file 'XXX' on file 1.
Processed 21 pages for database 'XXX', file 'XXX' on file 1.
BACKUP DATABASE successfully processed 1064693 pages in 58.533 seconds (142.106 MB/sec).

Peki suçlu hangisi, TOE veya LSO? TOE etkin, LSO devre dışı:

Didn't finish the backup as it took forever - just as the original problem!

TOE devre dışı, LSO etkin - iyi görünüyor:

Processed 1064680 pages for database 'XXX', file 'XXX' on file 1.
Processed 29 pages for database 'XXX', file 'XXX' on file 1.
BACKUP DATABASE successfully processed 1064709 pages in 59.073 seconds (140.809 MB/sec).

Ve bir kontrol olarak, sorunun çözüldüğünü onaylamak için hem TOE hem de LSO’yu devre dışı bıraktım:

Processed 1064720 pages for database 'XXX', file 'XXX' on file 1.
Processed 13 pages for database 'XXX', file 'XXX' on file 1.
BACKUP DATABASE successfully processed 1064733 pages in 60.675 seconds (137.094 MB/sec).

Sonuç olarak, etkinleştirilmiş Broadcom NIC’lerin TCP Boşaltma Motoru sorunlara neden oldu. TOE etkisiz hale gelir gelmez, her şey bir cazibe gibi çalıştı. Sanırım daha fazla Broadcom NIC’e ileriye dönük sipariş vermeyeceğim.

Güncelleme - Aşağı CIFS sunucusuna gidiyor
Bugün aynı ve işleyen CIFS sunucusu IO isteklerini askıya almaya başladı. Bu sunucu, SQL Server'ı çalıştırmıyordu, yalnızca düz Windows Web Server 2008 R2 CIFS üzerinden paylaşımlar yapıyordu. Bunun üzerine TOE'yi de etkisiz hale getirdiğim anda her şey yolunda gitmeye başladı.

Broadcom NIC’lerde hiç TOE kullanmayacağımı, Broadcom NIC’lerden hiç kaçınamayacağımı, yani.

Tüm sunucuların, güncel sürücülerle aynı NIC - Broadcom 5709C’leri kullandığını unutmayın. Sunucuların kendisi Dell R610's.

Kyle Brandt, Broadcom ağ kartları hakkında kendi (tekrarlanan) deneyimlerimi yansıtan bir görüşe sahip.

Broadcom, Mutha Die

Sorunlarım her zaman TCP Boşaltma özellikleriyle ilişkilendirildi ve vakaların% 99'unda devre dışı bırakma veya başka bir ağ kartına geçme, belirtileri çözdü. (Sizin durumunuzda olduğu gibi) Dell sunucuları kullanan, her zaman ayrı Intel NIC'ler sipariş eden ve yerleşik Broadcom kartlarını devre dışı bırakan bir müşteri.

Bu MSDN blog gönderisinde açıklandığı gibi , işletim sisteminde aşağıdakileri devre dışı bırakmakla başlardım:

netsh int ip set chimney DISABLED

IIRC bazı durumlarda kart sürücüsü seviyesindeki özelliklerin devre dışı bırakılması gerekebilir, ancak kesinlikle zarar vermez.

Bir SAN / disk uzmanı olduğumdan değil (benden daha çok şey bilen insanlar var) ... Sadece yaptığım şeyleri paylaşıyorum ve çoğunlukla okudum :)

Jonathan Kehayias ve Ted Krueger, disk performansı hakkında iyi bilgiler içeren bir "SQL Server Sorun Giderme" adlı bir kitap yazdı. PDF'yi buradan ücretsiz olarak alabilirsiniz . (Bunun basılı basımını da masam için satın alabilirim.)

Neyse, sys.dm_io_virtual_file_stats'ı kontrol etmek ve veri dosyalarınızdaki ortalama gecikmeyi kontrol etmek için kullanılabilecek iyi bir sorguları var. RAID10'un bulunduğu veri dosyaları için ideal yapılandırma olmadığını görebilirsiniz.