Windows 2003 server'lar arasında SMB ile dosya kopyalarken yaşanan bir performans sorunu
Tekrar merhaba,
Bugün sizlerle bir müsterimizin yasadigi SMB performans problemini ve nasil çözüme ulastigimizi paylasmak istiyorum. Öncelikle problemin detaylarini verecegim:
Problem tanimi:
============
Bir Microsoft Clusteri içinde çalisan Windows 2003 R2 SP2 x86 sunuculardan bazilarinda, uzaktaki baska bir sunucuya veri yedeklemesi yapilirken ciddi bir performans sorunu olusuyor. Daha önceden 8-9 saatte tamamlanan yedekleme, sorunun baslamasiyla birlikte 2 güne kadar çikmis. Ayrica müsterimiz, kendi yaptigi Windows Explorer ile dosya kopyalama testlerinde de ayni performans problemini olusturabilmis.
Yukaridaki problem tanimini müsterimizden aldiktan sonra hemen bir aksiyon plani olusturdum ve müsterimizin su loglari toplamasini istedim:
- Problem tekrar olusturulurken sorun yasayan serverlar üzerinde network trace toplanmasi
- Problem tekrar olusturulurken sorun yasayan serverlar üzerinde performance monitor loglari toplanmasi
- Ilgili server'lardan MPS reports log'u toplanmasi
Hemen belirtmekte fayda görüyorum, MPS reports logu bizim çok sik kullandigimiz bir sorun giderme araci. Neredeyse bütün çalistigimiz case'lerde müsterilerimizden bu logu istiyoruz. Çünkü bu log sorun yasayan sistemle ilgili olarak bizim ihtiyaç duyabilecegimiz pek çok bilgiyi otomatik olarak topluyor, örnegin:
- Event log'lar
- Server/Client'in network konfigürasyonu
- Server/Client üzerinde çalisan Microsoft ya da 3rd party driver detaylari
- Server üzerinde kurulu 3rd party yazilimlar ile ilgili detaylar
- Onemli registry key'lerin degerleri
- ...
Bu tool'un (Microsoft Product Support Reports) son sürümüne asagaki link'ten ulasabilirsiniz:
Tekrar konumuza dönersek, problem tekrar olusturulup loglar aksiyon plana uygun olarak toplandiktan sonra bana ulasti. Diger loglari da analiz etmekle birlikte ben özellikle network trace'ler üzerinde yogunlastim. Çünkü bu tür sorunlarda, bize problem ile ilgili en önemli ipuçlarini network trace'ler veriyor.
Network trace'de paketleri önce SMB protokolü ve source/destination IP adres çiftine göre filtreledikten sonra, time delta degerine göre büyükten küçüge dogru siraladim.
Not: Time delta, bir network trace içinde gözüken paketler arasinda kaç saniye geçtigini belirten bir deger ve network trace'ler üzerinden performans degerlendirmesi yapilirken kullanilabilecek çok önemli kriterlerden birisi.
Filtrelenmis ve time delta degerine göre siraya sokulmus network trace'de asagidaki problemi gördüm:
17959 0.310288 10.1.1.1 10.1.1.2 SMB [TCP Retransmission] Write AndX Request, FID: 0x4004, 61440 bytes at offset 17326080
66977 0.310280 10.1.1.1 10.1.1.2 SMB [TCP Retransmission] Write AndX Request, FID: 0x4004, 61440 bytes at offset 66908160
68860 0.309997 10.1.1.1 10.1.1.2 SMB [TCP Retransmission] Write AndX Request, FID: 0x4004, 61440 bytes at offset 68812800
63136 0.309995 10.1.1.1 10.1.1.2 SMB [TCP Retransmission] Write AndX Request, FID: 0x4004, 61440 bytes at offset 62976000
46542 0.309850 10.1.1.1 10.1.1.2 SMB [TCP Retransmission] Write AndX Request, FID: 0x4004, 61440 bytes at offset 46325760
23466 0.309577 10.1.1.1 10.1.1.2 SMB [TCP Retransmission] Write AndX Request, FID: 0x4004, 61440 bytes at offset 22855680
43025 0.309277 10.1.1.1 10.1.1.2 SMB [TCP Retransmission] Write AndX Request, FID: 0x4004, 61440 bytes at offset 42885120
...
Daha önceki bir blog'da da çok kisaca bahsettigim gibi (https://blogs.technet.com/platformtr/archive/2009/06/19/windows-xp-client-lar-n-dosya-kopyalarken-ya-ad-klar-bir-performans-problemi.aspx), SMB protokolü ile dosya kopyalamasi yapilirken "SMB Read AndX" ya da "SMB Write AndX" komutlari kullaniliyor. Bu senaryoda, üzerinde network trace alinan sistemden uzak bir server'a dosya kopyalandigi için "SMB Write AndX" komutlarini görüyoruz.
Sonuçta dosya kopyalamasinin yavas olmasina, bazi "SMB Write AndX" komutlarinin retransmit edilmesinin (yaklasik 0.3 saniye sonra) neden oldugu ortaya çikti. Bu noktayi genel olarak tespit ettikten sonra, belli bir örnek retransmission'i daha yakindan incelemeye karar verdim:
...
70261 0.004 10.1.1.1 10.1.1.2 SMB Write AndX Request, FID: 0x8007, 61440 bytes at offset 2273280
- Bu paket, 61140 byte'lik SMB payload'unun ilk 29132 byte'ini tasiyor. Bu bilgi frame header'dan görülebiliyor.
70905 0.200932 10.1.1.1 10.1.1.2 TCP [TCP Dup ACK 70261#1] 15902 > netbios-ssn [ACK] Seq=2309467 Ack=4051 Win=64617 Len=0
71335 0.109293 10.1.1.1 10.1.1.2 SMB [TCP Retransmission] Write AndX Request, FID: 0x8007, 61440 bytes at offset 2273280
- Server, yaklasik 0.3 saniye sonra, karsi tarafa ilk göndermis oldugu "SMB Write AndX" paketini retransmit ediyor.
Burada kaybedilen süre yaklasik 0.3 saniye. Buna benzer bir çok 0.3 saniyelik kayip birlestiginde, ortaya ciddi bir performans sorunu çikiyor.
Artik onemli olan bu kaybin neden olustugunu belirlemekte. Hemen bir noktayi açiklamakta yapmakta fayda görüyorum: Nasil oluyor da tek bir ethernet paketi içinde 29132 byte'lik veriyi karsi tarafa gönderebiliyoruz? (frame #70261). Bu özellik, Large Send Offloading (LSO) adi verilen bir optimizasyon sayesinde gerçeklesiyor. Bu özelligin kullanilabilmesi için, NIC driver'in LSO'yu desteklemesi gerekli. Kisaca bu özellik, TCPIP driver'in paket parçalama isini NIC driver'a birakmasi. NIC driver paketi parçaladiktan sonra genellikle ethernet MTU'suna göre network'e gönderiyor (1500 byte). Tabi network trace'i alan agent, henüz bu parçalama gerçeklesmeden paketi gördügü için de, biz sanki 29132 byte'lik data dogrudan network'e gönderilmis gibi görüyoruz. Daha ayrintili bilgiyi asagidaki linkten de alabilirsiniz:
https://www.microsoft.com/whdc/device/network/taskoffload.mspx Windows Network Task Offload
Tekrar yukaridaki örnege dönersem, "SMB Write AndX" komutunun önce LSO özelligi kullanilarak gönderildigini, retransmission'da ise bunun LSO kullanilmadan (yani parçalamayi TCPIP driver kendisi yapiyor, NIC driver'a yaptirmak yerine) gönderildigini ve bu kez bir sorun çikmadigini gördüm. Her 0.3 saniyelik paket retransmissionda'da ayni davranis vardi. Bu gözlemim sonucunda, problemin LSO ile ilgili bir sorun oldugu sonucuna vardim ve müsterimize LSO özelligini (NIC driver ayarlarindan) kapattirmaya karar verdim. LSO'nun bazi senaryolarda özellikle NIC driver ile ilgili sorunlardan dolayi performans problemleri yarattigi biliniyor ve bizim problem arsivlerimizde LSO'dan kaynaklandigi anlasilan problem kayitlari var. Genellikle sorun ya LSO özelligini disable ederek ya da NIC driver'i en güncel sekliyle kullanarak çözümlenebiliyor.
Not: Bu özelligi kapatmak için, NIC ayarlarindan "Advanced" bölümü seçip, oradan "Large Send offload" ya da benzeri isme sahip özelligi disable etmeniz gerekiyor. Burada göreceginiz isim NIC driver'dan NIC driver'a degisiklik de gösterebilir.
Sonuçta müsterimiz LSO özelligini kapattiktan sonra, SMB dosya kopyalama performans sorunu da ortadan kalkmis oldu.
Gelecek bloglarda görüsmek üzere,
Murat Kayacan