Windows XP client'ların dosya kopyalarken yaşadıkları bir performans problemi üzerine
Merhaba,
Ben Windows Platform Türkiye ekibinden Murat. Bugün sizlerle, çalistigim bir network probleminde nasil çözüme ulastigimi paylasmak istiyorum.
Üzerinde çalistigim problemde, Windows XP client'lar NAS (Network attached Storage) server'a çok yavas dosya kopyaliyorlardi. Özellikle bu tür sorunlar pek çok farkli nedenden kaynaklanabiliyor ve en önemli sorun giderme araçlarindan birisi de Network Monitoring araçlari. Baska blog'lar da bu konunun daha da ayrintisina ayrica girecegiz.
Tekrar soruna dönecek olursak, problemin nedenini daha iyi anlayabilmek için bir test client üzerinde network trace toplayip problemi tekrar olusturduk ve sonra bu network trace'in analizini yaptik. Isterseniz simdi biraz bunun ayrintilarina bakalim:
Windows networklerde dosya kopyalama islemi genellikle SMB protokolü üzerinden gerçeklestiriliyor. Windows 2000, XP ve 2003 sistemler SMBv1 kullanabilirken, Windows Vista, Windows server 2008 ve release olmak üzere olan Windows 7/Windows 2008 R2 sistemler ise hem SMBv1 hem de SMBv2 protokollerini kullanabilirler. Bizim sorunumuzda client taraf Windows XP oldugu için SMBv1 protokolü kullaniliyordu. SMBv1 protokolünde client, dosyayi SMB Create AndX komutu ile server üzerinde yarattiktan sonra (ya da mevcut bir dosyayi açtiktan sonra), ya SMB Read AndX komutlariyla (eger dosya server'dan client'a kopyalaniyorsa) ya da SMB Write AndX komutlariyla (eger dosya client'dan server'a kopyalaniyorsa), dosyayi server'a kopyalar (ya da server'dan kopyalar). Bizim senaryomuzda client dosyayi server'dan kopyaliyordu. Buna gore asagidaki adimlar gerçeklesecektir:
Client Server
SMB Create AndX request ---->
<---- SMB Create AndX response
SMB Read AndX request ----> (61440 bytes)
<---- SMB Read AndX response
SMB Read AndX request ----> (61440 bytes)
<---- SMB Read AndX response
SMB Read AndX request ----> (61440 bytes)
<---- SMB Read AndX response
SMB Read AndX request ----> (61440 bytes)
<---- SMB Read AndX response
Not: SMBv1 protokolünde client bir seferde server'dan en fazla 61440 byte'lik data isteyebilir.
Asagida, problem aninda toplanan trace'den bir alinti görebiliriz:
Frame# Time delta Source IP Destination IP Protocol Information
===== ======== ========= ========== ====== ========
....
59269 0.000000 10.1.1.1 10.1.1.2 SMB Read AndX Request, FID: 0x0494, 61440 bytes at offset 263823360
59270 0.000000 10.1.1.2 10.1.1.1 SMB Read AndX Response, 61440 bytes
59271 0.000000 10.1.1.2 10.1.1.1 TCP [Continuation to #59270] microsoft-ds > foliocorp [ACK] Seq=65993793
59272 0.000000 10.1.1.2 10.1.1.1 TCP [Continuation to #59270] microsoft-ds > foliocorp [ACK] Seq=65995249
59273 0.000000 10.1.1.2 10.1.1.1 TCP [Continuation to #59270] microsoft-ds > foliocorp [ACK] Seq=65996705
...
59320 0.000000 10.1.1.2 10.1.1.1 TCP [Continuation to #59270] microsoft-ds > foliocorp [ACK] Seq=66049121
59321 0.000000 10.1.1.2 10.1.1.1 TCP [Continuation to #59270] microsoft-ds > foliocorp [ACK] Seq=66050577
59322 0.000000 10.1.1.2 10.1.1.1 TCP [Continuation to #59270] microsoft-ds > foliocorp [ACK] Seq=66052033
59323 0.000000 10.1.1.1 10.1.1.2 TCP foliocorp > microsoft-ds [ACK] Seq=67600 Ack=66053489 Win=65535
59325 0.406250 10.1.1.2 10.1.1.1 TCP [Continuation to #59270] microsoft-ds > folioc [PSH, ACK]Seq=66053489
59326 0.000000 10.1.1.1 10.1.1.2 SMB Read AndX Request, FID: 0x0494, 61440 bytes at offset 263884800
59327 0.000000 10.1.1.2 10.1.1.1 SMB Read AndX Response, 61440 bytes
59328 0.000000 10.1.1.2 10.1.1.1 TCP [Continuation to #59327] microsoft-ds > foliocorp [ACK] Seq=66055297
...
Frame# 59269 => Client, FID: 0x0494 olan dosyanin (FID, dosya client tarafindan açilirken, server tarafindan atanan bir numaradir), 263823360. byte'indan itibaren 61440 byte okumak istedigini server'a bildiriyor
Frame# 59270 => Server, 61440 byte'lik data'yi client'a göndermeye basliyor.
Frame# 59271 => 61440 byte'lik data'nin yaklasik ilk 1440 byte'lik bölümü frame# 59270'de gönderildikten sonra, geri kalan kisimlari da bu frame ve takip eden diger frame'lerde gönderiliyor
Frame# 59272 => Data'nin yaklasik 1460 byte'lik kismi
Frame# 59273 => Data'nin yaklasik 1460 byte'lik kismi
..
Benim için bu aktivite içerisinde dikkat çeken sey, frame# 59325'de görülen yaklasik 0.4 saniyelik gecikmeydi. ("Time Delta" sütunu, iki frame arasindaki zaman farkini saniye cinsinde gösteriyor)
Network trace içinde yer alan paketleri "Time delta" sütununa göre siraladigimda, bu tür 0.4 saniyelik gecikmenin her 61440 byte'lik data blogu kopyalanirken olustugunu farkettim.
Normalde 0.4 saniye çok kisa bir zaman gibi gözükse de bir dosyayi kopyalarken yüzlerce SMB Read AndX gönderilmesi gerekebilegini düsündügümüzde bunun ciddi bir problem haline gelebilecegi çok net gözüküyor.
Normalde network trace'ler içinde gördügümüz gecikmeler paket kaybi, karsi sistemden kaynaklanan performans sorunlari, NIC driver problemleri gibi muhtelif nedenlerden kaynaklanabilir. Ancak düzenli olarak 0.4 saniyelik bir gecikme görüyor olmak, baska bir seyden süphelenmeme neden oldu: QoS
QoS (Quality of service), network üzerinde muhtelif politikalara göre data akisina müdahale edilmesini saglayan dolayisiyla daha önemli görülen trafigin
önceliklendirilmesini saglayan bir mekanizma. Ve bugün, pek çok ag cihazi (switch/router/vs) ve Windows isletim sistemleri QoS uygulamalarini destekliyor.
Müsterimize kendi network'lerinde bu tür bir QoS politikasinin uygulanmis olma ihtimalinden bahsettikten sonra, müsterimiz, gerçekten kendi ag cihazlari
üzerinde QoS uygulandigini ve bu kapatildiktan sonra problemin çözüldügünü söyledi.
Tesekkürler,
Murat Kayacan