Performans problemi ?


Bir performans sorununu çözebilmek, onu dogru anlayabilmek ile baslar. Sorunun taniminin analizini atlayamayiz. Tam anlasilmayan bir problem üzerinde hemen çalismaya baslarsak, muhtemelen sorunun tanimini belirlemeye hep geri dönüyor oluruz. Böylece tam anlasilmamis bir problem üzerinde çözüme yönelik troubleshooting yapmak çok büyük zaman kaybi olabilir.

Öncelikle sikayeti tanimlayan anahtar kelimeleri dinlemeliyiz: unresponsive, yavas , takiliyor, hang oluyor, donuyor. Sonra bu tanimlayici kelimelerin neyi kapsadiklarini anlamaliyiz. Yani örnegin: ne donuyor? Yavas olan ne ve neye göre yavas? Isletim sistemi mi, yazilim mi? Mouse/klavye etkileniyor mu? Taskbar etkileniyor mu? Ne zaman ne yapinca ne oluyor ve kullanici ne yapiyor/tam olarak ne gözlemliyor. Bir kullanicinin bize durumu anlatabilmesi, kullanici kim olursa olsun zor olabilir. Yasanan semptomlarda hangi detaylarin önemli olup olmadiklarini bilmiyor olabilir. Dogru sorulari sorarak hem sikayeti olan kullaniciyi çözüme dahil edebiliriz ve belki egitebiliriz; hem de elbette sorunu anlayabilirsiniz. Takiben dogru adimlar ile sorunu teknik anlayip çözüme dogru ilerleyebiliriz.

Bir sefer yasanmis bir sorundan ancak yeterince bilgi alamiyor olabiliriz ve sorunu anlayabilmek için sorunun tekrarlamasini beklememeiz gerekebilir. Örnegin bir sunucuda yasanan bir performans sorunu ile ilgili bu sorularda çok önemlidir. Sorun esnasinda ping atilabiliyor mu? Sunucuya RDP yapilabiliniyor mu? Direk fiziki konsolda olundugunda sorun ile ilgili degisik bir durum söz konusu oluyor mu? Burada sisteme müdahale edilebiliyor mu? Task manager açilabiliniyor mu ve burada herhangi göze çarpan bir sey oluyor mu? Sunucunun asil vazifeleri çalismaya devam ediyorlar mi? Örnegin üstünde SQL çalisiyorsa, sunucuya belki baglanamazsak da SQL in kendisi querry lere cevap dönüyor mu? Son olarak: sorunun frekansi ne? Yani ne kadar çok ve belki hangi sartlar altinda tekrarliyior? Sorun olustu mu ne kadar sürüyor? Ve en önemlisi sorun olustu mu giderilmesi için ne yapiliyor? Kendiliginden mi geçiyor veya örnegin bir servis restart ediliyor veya sunucunun kendisi mi restart ediliyor? Belkide sunucunun kendisi restart oluyor?

Böylece yanlis anlasilmalari öncelikle gidermis oluyoruz. Makine donuyor sanilabiliyor olabilir, ama belki sadece (geçici) bir network sorunu olusuyordur. O zaman network tarafina fokus olmak gerekir. Sunucu restart oluyor olabilir ve bu donanimsal olabilir veya sunucu mavi ekrana düsüyordur. Isletim sistemi yavasliyor veya cevap vermemeye basliyor olabilir; veya bir yazilim farkli semptomlar gösteriyor olabilir.

Ayrica sorunun dogasini da anliyor oluruz. Yavaslama/Donma sorunu örnegin her sunucu rebootan sonra yaklasik bir hafta içinde hep tekrarliyorsa ve burada geçici çözüm için sadece reboot yapilabiliniyorsa, sorunun kaynagi muhtemelen en az bir isletim sistemi kaynaginin tükenmesi ile alakalidir. Sorun ama kendiliginden geçiyor ve belki düzensiz olusuyorsa, bunun kaynagi o zaman is yükündeki degisiklikler ile korele ediyor olabilir; veya belki bir servis crash olup bastan basliyordur.

Troubleshootda event loglarindan baslariz. Burada system ve application eventloglari çok yardimci olurlar. Sorundan hemen önce veya sorundan daha uzun zaman önce düsmeye baslayan warning ve error eventler yardimci olabilirler. Burada örnegin NIC lerin servis adlarindan networksel sorunlar ile ilgili eventler düsmüs olabilir (msinfo32, components, network, adapter dan her fiziki ve snal network adaptörün Service Name ini görebilirsiniz, bu ayni zamanda eventlog da source u olarak görüntülenir). Yüklü aygit sürücüleri veya isletim sisteminin aygit sürücüleri network, disk ile ilgili hatalar düsüyor olabilir. Yazilimlar kayit düsebilir veya crash olan yazilimlar hakkinda bilgi edinebiliriz.

Yaygin bir sorun, makinenin kendiliginden reboot olmasi ve bunun nedeninin anlasilmamasi. Eger donanimin yazilimlari kurulmus ise bunlar sunucuyu kapanmadan/restart edilmeden event düsüyor olabilirler. Örnegin isi sorunu olmus olabilir. Baska bir kullanici reboot ediyor olabilir. USER32 den 1074 information eventler burada yardimci olabilirler. Mavi ekran olusmus ise USER32 den 1076 event in içinde ‘Bugcheck String’ den sonra stop hatasini görebiliriz. Ancak bu maalesef %100 dogru degil.

Mavi ekran olusur ve isletim sistemi bellek verilerini page file a yazar; takip eden boot da dump dosyasini olusturur ve eventi yazar. Belki BIOS da Automatic System Restart veya benzeri bir teknoloji açiktir. Mavi ekrana düstükten sonra donanim sunucuyu restart ediyordur ve isletim sisteminin bilgileri yazma sansi olmuyordur. O durumda rebootdan sonra ne olup bittiginden haberimiz olmaz. Belki de mavi ekranda page file a erisemiyoruzdur. En nihayetinde mavi ekran isletim sisteminin ciddi bir sorun fark ettigini ve koruma amaçli reboot etmesidir. Bu esnada en temel sürücüler loaded kalir ve bellek bilgileri sonradan sorunu anlayabilmek için kayit edilir. Bu temel sürücüler durumunda isletim sistemi kompleks disk yapilarina erisemiyor olabilir ve C: de degil de örnegin F: SAN diskinde sadece bir pagefile duruyorsa bu page file a erisilemiyor olabilir. Ikinci sorun dump dosyasinin yazilmamasi veya corrupt olmasi olabilir. Dump örnekteki F: ye yaziliyorsa boot un erken asamasinda erisilemiyor durumda olabilir. Dumpin yazildigi diskde yeterince bos yer olmayabilir.

Dumpimiz varsa, default C:\Windows\memory.dmp, bunu inceleyip mavi ekranin nedenini anlayabiliriz. Bu tarz ‘crash’ dumplarin analizi çogunlukla kolaydir. Analiz etmek için Debugging tools for Windows un uygun versiyonunu kurmamiz gerekir:
http://msdl.microsoft.com/download/symbols/debuggers/dbg_x86_6.11.1.404.msi
http://msdl.microsoft.com/download/symbols/debuggers/dbg_ia64_6.11.1.404.msiVe sembolleri indirebilecegimiz sunucuyu ve sembolleri lokalde tutulacagi lokasyonu belirlememiz gerekir. Windbg de Symbol file path de: SRV*C:\LokalSembolCache*http://msdl.microsoft.com/download/symbols
Seklinde girebiliriz. Sonra windbg den dumpi açtiktan sonra ‘!analyze -v’ komutu ile mavi ekrana neden olmus thread in stackini görebiliriz. Stack asagidan yukariya okunur. Eger elimizde sadece bir minidump (C:\Windows\Minidump) varsa, zaten bu komut disinda pek fazla yaklasim kalmaz.
Burada stack de gördügünüz modülleri güncellemeyi deneyebilirsiniz. Her frame/satir da ! öncesi functioncall u yapan modüldür, bu modül hakkinda daha fazla bilgi de edinebilirsiniz. Örnegin modül ntfs (ntfs.sys) ise, ‘lmvm ntfs’ komutu ile detaylari listeleyebilirsiniz. En önemlisi windbg in help inde örnegin C1 için 0x000000C1 formatinda bug check i aratirmakdir. Bug check sayfalari çok yarimci olabilir.
Konu ile ilgili olarak bu videoyu izleyebilirsiniz: http://technet.microsoft.com/en-us/ff606436.aspx

Isletim sistemi ama sorunlu durumu kendisi algilamiyorsa kesinlikle bir performans monitör logu çalistirmaliyiz. Arti sorun aninda manuel bir dump almayi da deneyebiliriz.
Manuel dump alma opsiyonlarin detaylari için: http://support.microsoft.com/kb/969028
Eger
makineye erisebiliyorsak notmyfault ile dump alabiliriz, eger bu mümkün degilse ve sunucu keyboard mouse seviyesinin üsütnde sorun yasiyorsa keyboard dan dump alabilir. Eger ama bu da mümkün degilse sadece donanim üzerinden, processor e NMI göndererek dump alabiliriz.
Bu tarz bir memory ‘hang’ dumpimiz varsa, ve burada çok önemli nokta dumpin sorun esnasinda alinmis olmasi, asagidaki komutlar ile sorunlu olabilecek bölgelere bakabiliriz: !locks birbirini bloke eden threadleri bulabilmek için, !vm bellek ile ilgili detaylari görebilmek için, !poolused 2 ve !poolused 4 kernel poollari hakkinda daha fazla bilgi için, Lm yüklenmis modüllerin listesi için. !thread ve takip eden thread ID si ile bir threadin içerigini görebiliriz. .thread ile fokus u o threade verip k komutlarini çalistirabiliriz: k, kv, kb, kpn. Daha detayli dump analizi için mimari bilgimizi gelistirmemiz gerekir: http://technet.microsoft.com/en-us/sysinternals/bb963901


Performance monitör logu
olusturmak için örnegin bu komutu run as admin olarak çalistirabiliriz:
‘logman.exe create counter Perf-Counter-Log -v mmddhhmm -max 300 -c "\LogicalDisk(*)\*" "\Memory\*" "\Network Interface(*)\*" "\Paging File(*)\*" "\PhysicalDisk(*)\*" "\Process(*)\*" "\Processor(*)\*" "\Redirector\*" "\Server\*" "\System\*" -si 00:10:00’
Yukaridaki counterlar ile her 10 dakikada bir snapshot alinir ve 300MB de yeni bir log baslatilir.
Logu Performance Monitor altindaki, Data Collector Sets, User Defined altinda bulabiliriz. Buradan veya ‘logman start Perf-Counter-Log’ komutu ile baslatabiliriz. Loglar C:\PerfLogs\Admin altina yazilir. Snapshort intervali önemlidir. Ne kadar küçük bir deger seçersek kisa sorunlari kaçirma sansimiz o kadar düser. Ancak ne kadar yüksek seçersek de bos veri gelme sansi düser ve log boyutu da düser. Baslatilmis bir log rebootdan sonra yine baslar.
Performance monitörü direk açtiginizda her counter in description ni görebilirsiniz. Log larda bakabilecegimiz standart bölgeler:
Paging file\% Usage %10 altinda olmali, yoksa yavasliga neden olabilir. Process\Page File Bytes dan kullanan process leri görebiliriz.
Memory\Available Mbytes bos fiziki RAM I gösterir ve asla 500MB altina düsmesi önerilmez. Process\Working Set den process kullanimlarini görebiliriz. 32 bit de /PAE kullaniliyorsa, bos yer çok görünebilir, ancak isletim sistemi sadece yine 4GB a kadar kullanabilir. 4GB üstünü ancak AWE kullanan yazilimlar (örnegin SQL) kullanabilir. PAE hakkinda: http://msdn.microsoft.com/en-us/library/aa366796%28v=VS.85%29.aspx
Processor\%Processor Time, ne kadar basit olsada her ihtimale karsi bakmak gerekir.
Memory\ Free System Page Table Entries, 32 bit de 10 bin in altina düsmemeli. Yoksa er türlü sorunlarimiz olusabilir, bitene kadar: Bug Check 0x3F: NO_MORE_SYSTEM_PTES
Memory\Pool Nonpaged ve Paged Bytes, Kernel totalleri, detaylari ancak dump da poolused komutlari ile görebiliriz (yada memsnap.exe ile: Memsnap -p c:\memsnap.log komutuyla log olusturarak). 32 bit de ilki yaklasik 256MB ye kadar, ikincisi de yaklasik 512MB ye kadar kullanilabilir. /3GB bu degerleri yarilar. /userva kernelden geri aldigi adres bölgesini sadece PTE lere verir: http://support.microsoft.com/kb/316739
Network Interface\Bytes Total/sec ve Network Interface\Current Bandwidth
, absürd degerler teaming, nic sürücüsü veya firmware den kaynaklaniyor olabilir. Unutmayalim, bandwidth degeri sürücüden isletim sistemine yansitilan deger. Isletim sistemi, bu deger ile çalisir ve bu beklenen den farkli olabilir. NIC ayarlarini kontrol etmek faydali olabilir.
Process\Handle ve Thread Count, buarada bir process in bir handle veya thread leak i olabilir. Yani sürekli yeni yaratip, eskileri silmiyor olabilir. Uzun vadeli logda bunu grafik den görmek kolay olur.

Disk tarafi yavasliga neden olabilen bir numarali bölümdür:
Physical Disk\%Idle Time, ne kadar düsükse kisaca disk de o kadar yogundur. Ortalamada en kötü durumda yaklasik %60 in altina düsmemesi önerirlir. 0, disk IO alamiyor demektir.
LogicalDisk vs. PhysicalDisk, physical gerçekden disk management da gördügümüz diskler, logical volüm/partisyonlar.
LogicalDisk\%Free Space, destek açisindan hep en az %10-15 önerilir.
PhysicalDisk\SplitIO , 0.000 e mümkün oldugunca yakin olmali. Degilse: yeterince bos yer yok, NTFS veya RAID boyutlari çok küçük, diskde en az orta seviyeli fragmentasyon var. Bu ne kadar bölünmüs IO yapmak zorunda oldugumuzu gösterir.
PhysicalDisk\Avg. Disk sec/Read ve /Write. Bu diskdeki gecikmeleri gösterir. Bir yazma/okuma IO su yaparken ne kadar beklenildigi. Burada ortalama degerin 20ms yi, yani 0.020 yi geçmemesi önerilir. Yüksek IO gecikmeleri çok farkli sorunlara neden olabilirler. Current disk queue length de sismeye baslar, bu da herhangi bir IO yapilirken siraya giren IO un önünde bekleyen IO un rakamidir. Ortalamada 2 yi geçmemesi önerilir. Özellikle SAN ortamlarinda bu tarz yavasliklara isletim sisteminin IO in stackinde çok zaman harcayan modüller neden olabilirler. Isletim sistemine yüklenen her aygit sürücüsü kendisini IO manager ile register eder. Sonra her IOda da IO manager o sürücüleri dahil eder. Burada sorunlu modüller her türlü performans nedenine sebep olabilirler. Ondan antivirüs ve diger sürücüler güncel tutulmalidirlar. Ayni sekilde HBA ve Controller in firmwareleri de güncel olmalidirlar. Burada üreticinin supportability matrix deki detaylar uyarlanmalidirlar. Ama en nihayetinde performans sorunun kaynagi donanimin yetmemesi olabilir ve burada ancak masrafli bir çözüm olabilir.
PhysicalDisk\Disk Write Bytes/sec ve PhysicalDisk\Disk Read Bytes/sec, bize disklere yapilan throughput u gösterirler.
Process\IO Data Bytes/sec de her processin yaptigi IO yu gösterir (ancak buna network dahildir).
Perfmon log analizi için iki temel yaklasim vardir. Biri sadace degerlere bakmak, bir tarz threshold analizi yapmak ve bunu farkli toollar ile de yapabilirsiniz. Diger yaklasim grafiksel analiz, korelasyonlara bakmak ve gelismeleri incelemek.

Perfmon verileri yaratmaz. Isletim sistemi bunlari standart hep toplar/sunar. Perfmon bu verileri sadece alir ve bir loga yazar.

Yukaridaki performance monitör yaklasimini sorunlu process/yazilim için de kullanabiliriz. En nihayetginde processlerin bütün özelliklerini takip edebiliririz. Ancak bir processin içinde ne döndügünü anlamak için dumpa ihtiyacimiz olur. Burada ya yukaridaki gibi bir memeory dump alabiliriz, complete memory dump (sadece Kernel degil, user mode adres bölgesini de kapsiyor olmali). Bu gereksiz ve çok zahmetli olabilir ve ço zaman gerekmemektedir. Daha basit sekilde bir process dump alabiliriz.
‘Hang’ dump almak istiyorsak, bunu task managerda yapabiliriz: process e sag tiklayip ‘create dump file’ diyebiliriz.
Crash olan bir process/servisi ancak bu sekilde yakalayamayiz. Burada istedigimiz process crash oldugunda dumpi alabilmek, isletim sisteminin mavi ekrani gibi.
Bunu yine Debugging Tools for Windows ile yapabiliriz. Burada windbg in yaninda adplus diye bir tool vardir.
‘cscript /h:wscript’ komutu ile adplus i default debugger yapariz ve ‘adplus.vbs -crash -quiet -pn spoolsv.exe -o c:\temp’ ile bir process e attach olabiliriz, burada örnegin print spooler servisine. Sonra servis crash olursa, dumpimiz olur. Burada dumpi aldigimiz makinede sembollere ihtiyacimiz yoktur, bunun ile ilgili uyarilar önemli degildir.
Servis ama ‘’takiliyorsa’’, yeni cevap vermiyor ama crash de olmuyorsa, ‘hang’ dumpini almak daha mantikli olabilir. Bunu ya task manager dan yada ayni adplus komutu ile sadece -crash yerine -hang yazarak yapabiliriz.
User mode da yine !analyze –v yardimci olabilir. Ama hang dumpimiz varsa !locks lara yine bakabiliriz. Process in içindeki bütün threadleri detayli sekilde listeleyebiliriz: ‘~*kpn’ . Ayrica, örnegin bir process yüksek cpu yapiyorsa ve bunun yaklasik ne zaman basladigini biliyorsak dump da ‘!runaway’ komutu ile threadlerin ne zaman basladiklarini görebiliriz. Böylece hangi threadin buna neden oldugunu bulabiliriz. Memory dumpdaki ‘.thread’, user mode da: ‘~NUMARSIs’, ama ‘~*kpn’ den sonra da görebilirsiniz.
Semboller elbette Microsoftun ürünlerinin. Baska üreticilerin modülleri hakinda dumplarad hiçbir detay göremiyor olabilirsiniz.

User mode tarafindaki process aktivitelerini takip etmek için iki harika tool daha vardir:
Procmon http://technet.microsoft.com/en-us/sysinternals/bb896645 ve
Process Monitor http://technet.microsoft.com/en-us/sysinternals/bb896653
Procmon ile bir sorunu kayit edip sonra processlerin her türlü (file, registry) aktivitelerini filtreleyebiliriz. Örnegin Access Denied aliyorsak, bunu logda tam olarak nerede aldigimizi görebiliriz. Process monitörde örnegin her svchostun içerigini sadece mouse ile üstünden geçerek görebiliriz. Dump almadan threadlerin stacklerini görebiliriz.

Büyük adimlar atmadan bu toolar ile bakmak durumu anlamak adina çok sey hizlandirabilir.


Ek
linkler:
http://support.microsoft.com/kb/294418 Comparison of 32-bit and 64-bit memory architecture for 64-bit editions of Windows XP and Windows Server 2003
Eger perfmon counterlar ile sorunlar varsa: http://support.microsoft.com/kb/2554336 How to manually rebuild Performance Counters…
http://support.microsoft.com/kb/972110 How to generate a kernel dump file or a complete memory dump file in Windows Server 2003
http://support.microsoft.com/kb/969028 How to generate a kernel or a complete memory dump file in Windows Server 2008
http://support.microsoft.com/kb/927069 How to generate a complete crash dump file or a kernel crash dump file by using an NMI on a Windows-based system
http://support.microsoft.com/kb/303021 How to Generate a Memory Dump File When a Server Stops Responding (Hangs)
http://support.microsoft.com/kb/254649 Overview of memory dump file options for Windows Vista, Windows Server 2008 R2, Windows Server 2008, Windows Server 2003, Windows XP, and Windows 2000
http://support.microsoft.com/kb/311503 Use the Microsoft Symbol Server to obtain debug symbol files
http://msdn.microsoft.com/en-us/library/x54fht41(VS.80).aspx How to: Specify a Symbol Path
http://support.microsoft.com/kb/886670 Memsnap ile ilgili bilgi.

Basar Güner


Comments (0)