it-swarm.asia

Permintaan I / O membutuhkan waktu lebih dari 15 detik

Biasanya backup penuh mingguan kami selesai dalam waktu sekitar 35 menit, dengan backup harian yang selesai dalam ~ 5 menit. Sejak selasa harian telah menghabiskan hampir 4 jam untuk menyelesaikan, cara yang lebih dari yang diperlukan. Secara kebetulan, ini mulai terjadi tepat setelah kami mendapatkan konfigurasi SAN/disk baru.

Perhatikan bahwa server berjalan dalam produksi dan kami tidak memiliki masalah secara keseluruhan, ini berjalan dengan lancar - kecuali untuk masalah IO yang terutama dimanifestasikan dalam kinerja cadangan.

Melihat dm_exec_requests selama pencadangan, pencadangan selalu menunggu di ASYNC_IO_COMPLETION. Aha, jadi kami memiliki pendapat disk!

Namun, baik MDF (log disimpan pada disk lokal) maupun drive cadangan tidak memiliki aktivitas apa pun (IOPS ~ = 0 - kami memiliki banyak memori). Panjang antrian disk ~ = 0 juga. CPU berkisar sekitar 2-3%, tidak ada masalah di sana juga.

The SAN adalah Dell MD3220i, LUN terdiri dari 6x10k SAS drive. Server terhubung ke SAN melalui dua jalur fisik, masing-masing melalui sakelar terpisah dengan koneksi redundan ke SAN - total empat jalur, dua di antaranya aktif setiap saat. Saya dapat memverifikasi bahwa kedua koneksi aktif melalui task manager - membagi beban dengan sempurna secara merata Kedua koneksi menjalankan dupleks penuh 1G.

Kami dulu menggunakan bingkai jumbo, tapi saya telah menonaktifkannya untuk menyingkirkan masalah apa pun di sini - tidak ada perubahan. Kami memiliki server lain (konfigurasi OS + yang sama, 2008 R2) yang terhubung ke LUN lain, dan tidak menunjukkan masalah. Namun tidak menjalankan SQL Server, tetapi hanya berbagi CIFS di atas mereka. Namun, salah satu jalur yang dipilih LUN berada pada controller SAN yang sama dengan LUN yang bermasalah - jadi saya sudah mengesampingkan hal itu juga.

Menjalankan beberapa tes SQLIO (file tes 10G) tampaknya menunjukkan bahwa IO layak, meskipun ada masalah:

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

Saya menyadari bahwa ini bukan tes yang lengkap dengan cara apa pun, tetapi mereka membuat saya nyaman mengetahui bahwa itu bukan sampah lengkap. Perhatikan bahwa kinerja penulisan yang lebih tinggi disebabkan oleh dua jalur MPIO aktif, sedangkan membaca hanya akan menggunakan salah satunya.

Memeriksa log peristiwa Aplikasi mengungkapkan peristiwa seperti ini tersebar di sekitar:

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

Mereka tidak konstan, tetapi mereka memang terjadi secara teratur (beberapa per jam, lebih banyak selama pencadangan). Di samping peristiwa itu, log peristiwa Sistem akan memposting ini:

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.

Ini juga terjadi pada server CIFS yang tidak bermasalah berjalan pada SAN/Controller yang sama, dan dari Googling saya mereka tampaknya tidak kritis.

Perhatikan bahwa semua server menggunakan NIC yang sama - Broadcom 5709Cs dengan driver terbaru. Server sendiri adalah Dell R610.

Saya tidak yakin apa yang harus diperiksa selanjutnya. Ada saran?

Pembaruan - Menjalankan perfmon
Saya mencoba merekam Rata-rata. Disk detik/Baca & Tulis penghitung perf saat melakukan pencadangan. Cadangan dimulai dengan luar biasa, dan kemudian pada dasarnya berhenti mati di 50%, merangkak perlahan menuju 100%, tetapi mengambil 20x waktu yang seharusnya.

Task monitor during start of backup Memperlihatkan keduanya SAN jalur sedang digunakan, lalu menurun.

Perform during same Pencadangan dimulai sekitar 15:38:50 - perhatikan semua terlihat bagus, dan kemudian ada serangkaian puncak. Saya tidak peduli dengan menulis, hanya membaca yang tampaknya menggantung.

Task monitor during end of backup Catat sedikit aksi on/off, meskipun kinerja menyala di akhir.

Perfmon during same Perhatikan maksimum 12 detik, meskipun rata-rata secara keseluruhan bagus.

Pembaruan - Mencadangkan ke perangkat NUL
Untuk mengisolasi masalah membaca dan menyederhanakan hal-hal, saya menjalankan yang berikut:

BACKUP DATABASE XXX TO DISK = 'NUL'

Hasilnya persis sama - dimulai dengan membaca burst dan kemudian warung, melanjutkan operasi sekarang dan kemudian:

Results

Pembaruan - IO warung
Saya menjalankan kueri dm_io_virtual_file_stats dari Jonathan Kehayias dan Ted Kruegers buk (halaman 29), seperti yang direkomendasikan oleh Shawn. Melihat 25 file teratas (masing-masing satu file data - semua hasil berupa file data), sepertinya membaca lebih buruk daripada menulis - mungkin karena menulis langsung menuju ke cache SAN sedangkan cold reads perlu menekan disk - tebak saja.

IO Stalls

Pembaruan - Tunggu statistik
Saya melakukan tiga tes untuk mengumpulkan beberapa statistik tunggu. Statistik tunggu dipertanyakan menggunakan Glenn Berry/Paul Randals skrip . Dan hanya untuk mengonfirmasi - backup tidak dilakukan untuk merekam, tetapi untuk LUN iSCSI. Hasil serupa jika dilakukan ke disk lokal, dengan hasil yang mirip dengan cadangan NUL.

Statistik yang dihapus. Berlari selama 10 menit, beban normal: No backup

Statistik yang dihapus. Berlari selama 10 menit, pemuatan normal + pencadangan normal berjalan (tidak selesai): Normal backup

Statistik yang dihapus. Berlari selama 10 menit, beban normal + pencadangan NUL berjalan (tidak selesai): NUL backup

Pembaruan - Wtf, Broadcom?
Berdasarkan saran Mark Storey-Smiths dan pengalaman Kyle Brandts sebelumnya dengan Broadcom NICs, saya memutuskan untuk melakukan beberapa eksperimen. Karena kami memiliki beberapa jalur aktif, saya dapat dengan mudah mengubah konfigurasi NIC satu per satu tanpa menyebabkan gangguan.

Menonaktifkan TOE dan Kirim Besar-Lepas menghasilkan hampir sempurna: enter image description here

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).

Jadi yang mana pelakunya, TOE atau LSO? TOE diaktifkan, LSO dinonaktifkan: enter image description here

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

TOE dinonaktifkan, diaktifkan LSO - terlihat bagus: enter image description here

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).

Dan sebagai kontrol, saya menonaktifkan TOE dan LSO untuk mengonfirmasi bahwa masalah telah hilang: enter image description here

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).

Kesimpulannya tampaknya Broadcom NICs yang diaktifkan TCP Offload Engine menyebabkan masalah. Begitu TOE dinonaktifkan, semuanya bekerja seperti pesona. Sepertinya saya tidak akan memesan lagi NIC Broadcom yang akan datang .

Pembaruan - Turunnya server CIFS
Hari ini server CIFS yang identik dan berfungsi mulai menampilkan IO permintaan menggantung. Server ini tidak menjalankan SQL Server, sekadar Windows Web Server 2008 R2 yang melayani pembagian lebih dari CIFS. Segera karena saya menonaktifkan TOE di atasnya juga, semuanya kembali berjalan dengan lancar.

Hanya mengonfirmasi bahwa saya tidak akan pernah menggunakan TOE di Broadcom NIC lagi, jika saya tidak bisa menghindari NIC Broadcom sama sekali, itu.

31

Perhatikan bahwa semua server menggunakan NIC yang sama - Broadcom 5709Cs dengan driver terbaru. Server sendiri adalah Dell R610.

Kyle Brandt memiliki pendapat tentang kartu jaringan Broadcom yang menggemakan pengalaman saya sendiri (berulang).

Broadcom, Die Mutha

Masalah saya selalu dikaitkan dengan TCP Offload fitur dan dalam 99% kasus menonaktifkan atau beralih ke kartu jaringan a-n-lainnya telah menyelesaikan gejala. Satu klien yang (seperti dalam kasus Anda) menggunakan server Dell, selalu memesan Intel NIC terpisah dan menonaktifkan kartu Broadcom on-board yang sedang dibangun.

Seperti yang dijelaskan dalam ini posting blog MSDN , saya akan mulai dengan menonaktifkan di OS dengan:

netsh int ip set chimney DISABLED

IIRC mungkin perlu menonaktifkan fitur pada tingkat driver kartu dalam beberapa keadaan, tentu tidak ada salahnya untuk melakukannya.

14

Bukan berarti saya seorang ahli SAN/disk (ada orang-orang di sini yang tahu lebih banyak dari saya) ... Saya hanya membagikan apa yang telah saya lakukan sedikit dan kebanyakan membaca :)

Jonathan Kehayias dan Ted Krueger menulis sebuah buku "Mengatasi Masalah SQL Server" yang memiliki beberapa info bagus tentang kinerja disk. Anda bisa mendapatkan PDF gratis dari di sini . (Saya mungkin membeli edisi cetak ini juga untuk meja saya.)

Lagi pula mereka memiliki permintaan yang baik yang dapat digunakan untuk memeriksa sys.dm_io_virtual_file_stats dan memeriksa latensi rata-rata pada file data Anda. Anda mungkin menemukan bahwa RAID10 bukan konfigurasi ideal untuk tempat file data berada.

4
user507