Bir performans sorununu çözebilmek, onu doğru anlayabilmek ile başlar. Sorunun tanımının analizini atlayamayız. Tam anlaşılmayan bir problem üzerinde hemen çalışmaya başlarsak, muhtemelen sorunun tanımını belirlemeye hep geri dönüyor oluruz. Böylece tam anlaşılmamış bir problem üzerinde çözüme yönelik troubleshooting yapmak çok büyük zaman kaybı olabilir.

Öncelikle şikayeti tanımlayan anahtar kelimeleri dinlemeliyiz: unresponsive, yavaş , takılıyor, hang oluyor, donuyor. Sonra bu tanımlayıcı kelimelerin neyi kapsadıklarını anlamalıyız. Yani örneğin: ne donuyor? Yavaş olan ne ve neye göre yavaş? İşletim sistemi mi, yazılım mı? Mouse/klavye etkileniyor mu? Taskbar etkileniyor mu? Ne zaman ne yapınca ne oluyor ve kullanıcı ne yapıyor/tam olarak ne gözlemliyor. Bir kullanıcının bize durumu anlatabilmesi, kullanıcı kim olursa olsun zor olabilir. Yaşanan semptomlarda hangi detayların önemli olup olmadıklarını bilmiyor olabilir. Doğru soruları sorarak hem şikayeti olan kullanıcıyı çözüme dahil edebiliriz ve belki eğitebiliriz; hem de elbette sorunu anlayabilirsiniz. Takiben doğru adımlar ile sorunu teknik anlayıp çözüme doğru ilerleyebiliriz.

Bir sefer yaşanmış bir sorundan ancak yeterince bilgi alamıyor olabiliriz ve sorunu anlayabilmek için sorunun tekrarlamasını beklememeiz gerekebilir. Örneğin bir sunucuda yaşanan bir performans sorunu ile ilgili bu sorularda çok önemlidir. Sorun esnasında ping atılabiliyor mu? Sunucuya RDP yapılabiliniyor mu? Direk fiziki konsolda olunduğunda sorun ile ilgili değişik bir durum söz konusu oluyor mu? Burada sisteme müdahale edilebiliyor mu? Task manager açılabiliniyor mu ve burada herhangi göze çarpan bir şey oluyor mu? Sunucunun asıl vazifeleri çalışmaya devam ediyorlar mı? Örneğin üstünde SQL çalışıyorsa, sunucuya belki bağlanamazsak da SQL ın kendisi querry lere cevap dönüyor mu? Son olarak: sorunun frekansı ne? Yani ne kadar çok ve belki hangi şartlar altında tekrarlıyıor? Sorun oluştu mu ne kadar sürüyor? Ve en önemlisi sorun oluştu mu giderilmesi için ne yapılıyor? Kendiliğinden mi geçiyor veya örneğin bir servis restart ediliyor veya sunucunun kendisi mi restart ediliyor? Belkide sunucunun kendisi restart oluyor?

Böylece yanlış anlaşılmaları öncelikle gidermiş oluyoruz. Makine donuyor sanılabiliyor olabilir, ama belki sadece (geçici) bir network sorunu oluşuyordur. O zaman network tarafına fokus olmak gerekir. Sunucu restart oluyor olabilir ve bu donanımsal olabilir veya sunucu mavi ekrana düşüyordur. İşletim sistemi yavaşlıyor veya cevap vermemeye başlıyor olabilir; veya bir yazılım farklı semptomlar gösteriyor olabilir.

Ayrıca sorunun doğasını da anlıyor oluruz. Yavaşlama/Donma sorunu örneğin her sunucu rebootan sonra yaklaşık bir hafta içinde hep tekrarlıyorsa ve burada geçici çözüm için sadece reboot yapılabiliniyorsa, sorunun kaynağı muhtemelen en az bir işletim sistemi kaynağının tükenmesi ile alakalıdır. Sorun ama kendiliğinden geçiyor ve belki düzensiz oluşuyorsa, bunun kaynağı o zaman iş yükündeki değişiklikler ile korele ediyor olabilir; veya belki bir servis crash olup baştan başlıyordur.

Troubleshootda event loglarından başlarız. Burada system ve application eventlogları çok yardımcı olurlar. Sorundan hemen önce veya sorundan daha uzun zaman önce düşmeye başlayan warning ve error eventler yardımcı olabilirler. Burada örneğin NIC lerin servis adlarından networksel sorunlar ile ilgili eventler düşmüş olabilir (msinfo32, components, network, adapter dan her fiziki ve snal network adaptörün Service Name ini görebilirsiniz, bu aynı zamanda eventlog da source u olarak görüntülenir). Yüklü aygıt sürücüleri veya işletim sisteminin aygıt sürücüleri network, disk ile ilgili hatalar düşüyor olabilir. Yazılımlar kayıt düşebilir veya crash olan yazılımlar hakkında bilgi edinebiliriz.

Yaygın bir sorun, makinenin kendiliğinden reboot olması ve bunun nedeninin anlaşılmaması. Eğer donanımın yazılımları kurulmuş ise bunlar sunucuyu kapanmadan/restart edilmeden event düşüyor olabilirler. Örneğin ısı sorunu olmuş olabilir. Başka bir kullanıcı reboot ediyor olabilir. USER32 den 1074 information eventler burada yardımcı olabilirler. Mavi ekran oluşmuş ise USER32 den 1076 event in içinde ‘Bugcheck String’ den sonra stop hatasını görebiliriz. Ancak bu maalesef %100 doğru değil.

Mavi ekran oluşur ve işletim sistemi bellek verilerini page file a yazar; takip eden boot da dump dosyasını oluşturur ve eventi yazar. Belki BIOS da Automatic System Restart veya benzeri bir teknoloji açıktır. Mavi ekrana düştükten sonra donanım sunucuyu restart ediyordur ve işletim sisteminin bilgileri yazma şansı olmuyordur. O durumda rebootdan sonra ne olup bittiğinden haberimiz olmaz. Belki de mavi ekranda page file a erişemiyoruzdur. En nihayetinde mavi ekran işletim sisteminin ciddi bir sorun fark ettiğini ve koruma amaçlı reboot etmesidir. Bu esnada en temel sürücüler loaded kalır ve bellek bilgileri sonradan sorunu anlayabilmek için kayıt edilir. Bu temel sürücüler durumunda işletim sistemi kompleks disk yapılarına erişemiyor olabilir ve C: de değil de örneğin F: SAN diskinde sadece bir pagefile duruyorsa bu page file a erişilemiyor olabilir. İkinci sorun dump dosyasının yazılmaması veya corrupt olması olabilir. Dump örnekteki F: ye yazılıyorsa boot un erken aşamasında erişilemiyor durumda olabilir. Dumpın yazıldığı diskde yeterince boş yer olmayabilir.

Dumpımız varsa, default C:\Windows\memory.dmp, bunu inceleyip mavi ekranın nedenini anlayabiliriz. Bu tarz ‘crash’ dumpların analizi çoğunlukla kolaydır. Analiz etmek için Debugging tools for Windows un uygun versiyonunu kurmamız 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 indirebileceğimiz sunucuyu ve sembolleri lokalde tutulacağı lokasyonu belirlememiz gerekir. Windbg de Symbol file path de: SRV*C:\LokalSembolCache*http://msdl.microsoft.com/download/symbols
Şeklinde girebiliriz. Sonra windbg den dumpı açtıktan sonra ‘!analyze -v’ komutu ile mavi ekrana neden olmuş thread in stackini görebiliriz. Stack aşağıdan yukarıya okunur. Eğer elimizde sadece bir minidump (C:\Windows\Minidump) varsa, zaten bu komut dışında pek fazla yaklaşım kalmaz.
Burada stack de gördüğünüz modülleri güncellemeyi deneyebilirsiniz. Her frame/satır da ! öncesi functioncall u yapan modüldür, bu modül hakkında daha fazla bilgi de edinebilirsiniz. Örneğin modül ntfs (ntfs.sys) ise, ‘lmvm ntfs’ komutu ile detayları listeleyebilirsiniz. En önemlisi windbg in help inde örneğin C1 için 0x000000C1 formatında bug check i aratırmakdır. Bug check sayfaları çok yarımcı olabilir.
Konu ile ilgili olarak bu videoyu izleyebilirsiniz: http://technet.microsoft.com/en-us/ff606436.aspx


İşletim sistemi ama sorunlu durumu kendisi algılamıyorsa kesinlikle bir performans monitör logu çalıştırmalıyız. Artı sorun anında manuel bir dump almayı da deneyebiliriz.
Manuel dump alma opsiyonların detayları için: http://support.microsoft.com/kb/969028
Eğer
makineye erişebiliyorsak notmyfault ile dump alabiliriz, eğer bu mümkün değilse ve sunucu keyboard mouse seviyesinin üsütnde sorun yaşıyorsa keyboard dan dump alabilir. Eğer ama bu da mümkün değilse sadece donanım üzerinden, processor e NMI göndererek dump alabiliriz.
Bu tarz bir memory ‘hang’ dumpımız varsa, ve burada çok önemli nokta dumpın sorun esnasında alınmış olması, aşağıdaki komutlar ile sorunlu olabilecek bölgelere bakabiliriz: !locks birbirini bloke eden threadleri bulabilmek için, !vm bellek ile ilgili detayları görebilmek için, !poolused 2 ve !poolused 4 kernel poolları hakkında daha fazla bilgi için, Lm yüklenmiş modüllerin listesi için. !thread ve takip eden thread ID si ile bir threadin içeriğini görebiliriz. .thread ile fokus u o threade verip k komutlarını çalıştırabiliriz: k, kv, kb, kpn. Daha detaylı dump analizi için mimari bilgimizi geliştirmemiz gerekir: http://technet.microsoft.com/en-us/sysinternals/bb963901


Performance monitör logu
oluşturmak için örneğin bu komutu run as admin olarak çalıştırabiliriz:
‘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’
Yukarıdaki counterlar ile her 10 dakikada bir snapshot alınır ve 300MB de yeni bir log başlatılır.
Logu Performance Monitor altındaki, Data Collector Sets, User Defined altında bulabiliriz. Buradan veya ‘logman start Perf-Counter-Log’ komutu ile başlatabiliriz. Loglar C:\PerfLogs\Admin altına yazılır. Snapshort intervali önemlidir. Ne kadar küçük bir değer seçersek kısa sorunları kaçırma şansımız o kadar düşer. Ancak ne kadar yüksek seçersek de boş veri gelme şansı düşer ve log boyutu da düşer. Başlatılmış bir log rebootdan sonra yine başlar.
Performance monitörü direk açtığınızda her counter ın description nı görebilirsiniz. Log larda bakabileceğimiz standart bölgeler:
Paging file\% Usage %10 altında olmalı, yoksa yavaşlığa neden olabilir. Process\Page File Bytes dan kullanan process leri görebiliriz.
Memory\Available Mbytes boş fiziki RAM I gösterir ve asla 500MB altına düşmesi önerilmez. Process\Working Set den process kullanımlarını görebiliriz. 32 bit de /PAE kullanılıyorsa, boş yer çok görünebilir, ancak işletim sistemi sadece yine 4GB a kadar kullanabilir. 4GB üstünü ancak AWE kullanan yazılımlar (örneğin SQL) kullanabilir. PAE hakkında: http://msdn.microsoft.com/en-us/library/aa366796%28v=VS.85%29.aspx
Processor\%Processor Time, ne kadar basit olsada her ihtimale karşı bakmak gerekir.
Memory\ Free System Page Table Entries, 32 bit de 10 bin in altına düşmemeli. Yoksa er türlü sorunlarımız oluşabilir, bitene kadar: Bug Check 0x3F: NO_MORE_SYSTEM_PTES
Memory\Pool Nonpaged ve Paged Bytes, Kernel totalleri, detayları ancak dump da poolused komutları ile görebiliriz (yada memsnap.exe ile: Memsnap -p c:\memsnap.log komutuyla log oluşturarak). 32 bit de ilki yaklaşık 256MB ye kadar, ikincisi de yaklaşık 512MB ye kadar kullanılabilir. /3GB bu değerleri yarılar. /userva kernelden geri aldığı 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 değerler teaming, nic sürücüsü veya firmware den kaynaklanıyor olabilir. Unutmayalım, bandwidth değeri sürücüden işletim sistemine yansıtılan değer. İşletim sistemi, bu değer ile çalışır ve bu beklenen den farklı olabilir. NIC ayarlarını kontrol etmek faydalı olabilir.
Process\Handle ve Thread Count, buarada bir process in bir handle veya thread leak i olabilir. Yani sürekli yeni yaratıp, eskileri silmiyor olabilir. Uzun vadeli logda bunu grafik den görmek kolay olur.

Disk tarafı yavaşlığa neden olabilen bir numaralı bölümdür:
Physical Disk\%Idle Time, ne kadar düşükse kısaca disk de o kadar yoğundur. Ortalamada en kötü durumda yaklaşık %60 ın altına düşmemesi önerirlir. 0, disk IO alamıyor demektir.
LogicalDisk vs. PhysicalDisk, physical gerçekden disk management da gördüğümüz diskler, logical volüm/partisyonlar.
LogicalDisk\%Free Space, destek açısından hep en az %10-15 önerilir.
PhysicalDisk\SplitIO , 0.000 e mümkün olduğunca yakın olmalı. Değilse: yeterince boş yer yok, NTFS veya RAİD boyutları çok küçük, diskde en az orta seviyeli fragmentasyon var. Bu ne kadar bölünmüş IO yapmak zorunda olduğumuzu gösterir.
PhysicalDisk\Avg. Disk sec/Read ve /Write. Bu diskdeki gecikmeleri gösterir. Bir yazma/okuma IO su yaparken ne kadar beklenildiği. Burada ortalama değerin 20ms yi, yani 0.020 yi geçmemesi önerilir. Yüksek IO gecikmeleri çok farklı sorunlara neden olabilirler. Current disk queue length de şişmeye başlar, bu da herhangi bir IO yapılırken sıraya giren IO un önünde bekleyen IO un rakamıdır. Ortalamada 2 yi geçmemesi önerilir. Özellikle SAN ortamlarında bu tarz yavaşlıklara işletim sisteminin IO in stackinde çok zaman harcayan modüller neden olabilirler. İşletim sistemine yüklenen her aygıt 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 diğer sürücüler güncel tutulmalıdırlar. Aynı şekilde HBA ve Controller ın firmwareleri de güncel olmalıdırlar. Burada üreticinin supportability matrix deki detaylar uyarlanmalıdırlar. Ama en nihayetinde performans sorunun kaynağı donanımın yetmemesi olabilir ve burada ancak masraflı bir çözüm olabilir.
PhysicalDisk\Disk Write Bytes/sec ve PhysicalDisk\Disk Read Bytes/sec, bize disklere yapılan throughput u gösterirler.
Process\IO Data Bytes/sec de her processin yaptığı IO yu gösterir (ancak buna network dahildir).
Perfmon log analizi için iki temel yaklaşım vardır. Biri sadace değerlere bakmak, bir tarz threshold analizi yapmak ve bunu farklı toollar ile de yapabilirsiniz. Diğer yaklaşım grafiksel analiz, korelasyonlara bakmak ve gelişmeleri incelemek.

Perfmon verileri yaratmaz. İşletim sistemi bunları standart hep toplar/sunar. Perfmon bu verileri sadece alır ve bir loga yazar.

Yukarıdaki performance monitör yaklaşımını sorunlu process/yazılım için de kullanabiliriz. En nihayetğinde processlerin bütün özelliklerini takip edebiliririz. Ancak bir processin içinde ne döndüğünü anlamak için dumpa ihtiyacımız olur. Burada ya yukarıdaki gibi bir memeory dump alabiliriz, complete memory dump (sadece Kernel değil, user mode adres bölgesini de kapsıyor olmalı). Bu gereksiz ve çok zahmetli olabilir ve ço zaman gerekmemektedir. Daha basit şekilde bir process dump alabiliriz.
‘Hang’ dump almak istiyorsak, bunu task managerda yapabiliriz: process e sağ tıklayıp ‘create dump file’ diyebiliriz.
Crash olan bir process/servisi ancak bu şekilde yakalayamayız. Burada istediğimiz process crash olduğunda dumpı alabilmek, işletim sisteminin mavi ekranı gibi.
Bunu yine Debugging Tools for Windows ile yapabiliriz. Burada windbg in yanında adplus diye bir tool vardır.
‘cscript /h:wscript’ komutu ile adplus ı default debugger yaparız ve ‘adplus.vbs -crash -quiet -pn spoolsv.exe -o c:\temp’ ile bir process e attach olabiliriz, burada örneğin print spooler servisine. Sonra servis crash olursa, dumpımız olur. Burada dumpı aldığımız makinede sembollere ihtiyacımız yoktur, bunun ile ilgili uyarılar önemli değildir.
Servis ama ‘’takılıyorsa’’, yeni cevap vermiyor ama crash de olmuyorsa, ‘hang’ dumpını almak daha mantıklı olabilir. Bunu ya task manager dan yada aynı adplus komutu ile sadece -crash yerine -hang yazarak yapabiliriz.
User mode da yine !analyze –v yardımcı olabilir. Ama hang dumpımız varsa !locks lara yine bakabiliriz. Process in içindeki bütün threadleri detaylı şekilde listeleyebiliriz: ‘~*kpn’ . Ayrıca, örneğin bir process yüksek cpu yapıyorsa ve bunun yaklaşık ne zaman başladığını biliyorsak dump da ‘!runaway’ komutu ile threadlerin ne zaman başladıklarını görebiliriz. Böylece hangi threadin buna neden olduğunu bulabiliriz. Memory dumpdaki ‘.thread’, user mode da: ‘~NUMARSIs’, ama ‘~*kpn’ den sonra da görebilirsiniz.
Semboller elbette Microsoftun ürünlerinin. Başka üreticilerin modülleri hakında dumplarad hiçbir detay göremiyor olabilirsiniz.


User mode tarafındaki process aktivitelerini takip etmek için iki harika tool daha vardır:
Procmon http://technet.microsoft.com/en-us/sysinternals/bb896645 ve
Process Monitor http://technet.microsoft.com/en-us/sysinternals/bb896653
Procmon ile bir sorunu kayıt edip sonra processlerin her türlü (file, registry) aktivitelerini filtreleyebiliriz. Örneğin Access Denied alıyorsak, bunu logda tam olarak nerede aldığımızı görebiliriz. Process monitörde örneğin her svchostun içeriğini sadece mouse ile üstünden geçerek görebiliriz. Dump almadan threadlerin stacklerini görebiliriz.

Büyük adımlar atmadan bu toolar ile bakmak durumu anlamak adına çok şey hızlandırabilir.


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
Eğer 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.


Başar Güner