Debug Diagnostic Tool 1.1


IIS üzerinde çalışan uygulamalarda yaşadığımız sorunları birkaç kategoride toplayabiliriz:



  1. "Crash" sorunları (bunu nasıl Türkçe'ye çevireceğimi bilemedim, önerilere açığım)

  2. "Hang" sorunları

  3. Bellek kullanımı sorunları (memory leak)

  4. Performans sorunları

  5. Ağla ilgili sorunlar

Elbette bunların herbirinin farklı "teşhis" yolları bulunuyor. Bu yazımda ilk 4 tip sorun için kullandığımız Debug Diagnostic Tool'dan (DebugDiag) bahsedeceğim:


Debug Diagnostic Tool 1.1
http://www.microsoft.com/downloads/details.aspx?FamilyID=28bd5941-c458-46f1-b24d-f60151d875a3&DisplayLang=en


DebugDiag, sadece IIS/Web uygulamaları için değil, her türlü uygulama (process) için kullanabileceğimiz bir araçtır. En temel kullanım amacı, "memory dump" almaktır. Kabaca açıklamak gerekirse, "memory dump", bir uygulamanın o an kullandığı hafıza alanının bir dosyaya kaydedilmesidir. İşletim sistemimiz "mavi ekran"a düştüğünde (çoğu zaman) otomatik olarak dump alınır. Bu dumpta sadece bir uygulamanın kullandığı hafıza bölümü değil, tüm hafıza bulunur. Söz konusu web uygulamaları olduğunda, genelde bu kadar veriye ihtiyacımız olmayacaktır.


Yeri gelmişken şunu da belirteyim: Bu yazımda sadece dump almayla ilgili işlemlerden bahsedeceğim ama, ileride dump analizinden de bahsedeceğim. Şimdilik dump analizi ile ilgili başka blogların linkini paylaşmakla yetineceğim.


DUMP TÜRLERİ:


Debug Diagnostic Tool Rule Wizard


Aslında, bizim kullandığımız anlamda "dump"ların hepsi tek tiptir: Uygulamanın hafıza kullanımının anlık fotoğrafı. Buradaki "anlık fotoğraf" tabiri çok önemlidir. Aşağıda bunun neden önemli olduğundan bahsedeceğim. 


Dumpları, hangi sorun için ve nasıl alındığına göre şöyle bir sınıflandırabiliriz:



  1. Crash dump: "Crash" durumu, uygulamamızın (IIS 6.0 için w3wp.exe) bir sorundan ötürü kendi kendine kapanmasıdır. Bu durumun varlığını ya event loglarından, ya da kullanıcılardan gelen "session'lar kayboluyor" şikayetlerinden anlayabiliriz.
    Uygulamamız crash olduktan sonra bizim olaydan haberimiz olacağından, sorunla ilgili veri toplamak için çok geç kalmış oluruz (uygulama içerisindeki tüm verilerle beraber kapanmış ve hafızadan temizlenmiş olacaktır). Bu nedenle, crash dump almak için önceden hazırlık yapmamız gerekir.
    Bunun için DebugDiag'da bir kural tanımlamamız gerekiyor. Tek tek adımlardan bahsetmeyeceğim. DebugDiag'da bir "crash" kuralı tanımladığımızda, ilgili uygulamayı izlemeye başlar. Crash olacağını anladığında da dumpını alır.
     

  2. Hang dump: Teknik olarak "hang" sorunu, uygulamanın yenıt verememesi durumudur (geç yanıt verme durumu performans sorunudur, hang değil). Bu tür durumlarda uygulamamız 100% CPU tüketiyor olabileceği gibi, gelen isteklere rağmen hiç CPU tüketmiyor da olabilir. Bunların detaylarından başka yazılarda bahsedeceğim.
    Hang durumunda, crash'ten farklı olarak, sorun oluştuğunda uygulama kapanmadığından veri kaybetmiş olmayız. Bu nedenle önceden bir hazrılık gerektirmez. Her ne kadar DebugDiag'da hang için de kural tanımlayabiliyorsak da, ben onu kullanmayı tercih etmiyorum. Bunun yerine, sorun oluştuğunda DebugDiag'ı açıp, "processes" tabına geçin. Burada ilgili uygulamayı bulup üzerine sağ tıklayın. "Create full userdump"a tıkladığınız anda uygulamanın dumpı alınacaktır.
    Sadece hang değil, performans sorunlarında da yukarıdaki gibi "hang dump" alıp incelemek gerekecektir.
    Yukarıda bahsettiğim gibi, dump, uygulamanın anlık fotoğrafını çeker. Bu nedenle, örneğin yükcek CPU kullanımı sorunlarında, dump içerisinde neyin buna neden olduğunu görmek mümkğn değildir. En iyi ihtimalle tahminlerde bulunabiliriz. Bu yüzden, hang dump almamız gereken durumlarda, bir veya birkaç dakika arayla 2-3 defa dump almak gerekir. Böylece karşılaştırma yapmak mümkün olacaktır.
     

  3. Memory leak dump: Bu da aslında hang dumptır. Ancak, DebugDiag'da bir "memory leak" kuralı tanımladığımızda, "LeakTrack.dll" isimli bir uygulamayı bizim uygulamamıza "enjekte" eder. Bu da, uygulamamız çalışırken hafıza kullanımına dair bilgiler toplar. Bizim belirlediğimiz bir süre boyunca bu bilgileri topladıktan sonra hang dump alır.

Elbette dump almak, analiz edemedikten sonra bir işimize yaramayacaktır. DebugDiag'ın bir özelliği de aldığımız dumpları kendisinin analiz edebilmesidir.


Debug Diagnotic Tool Advanced Analysis


Sonuçta oluşturacağı rapor bazen sorunun tespitinde ve çözümünde çok faydalı olabilmektedir. Ama çoğu zaman analizi sizin yapmanız gerekecektir, ki bunun detaylarından daha sonra bahsedeceğiz. Aşağıda dump analizi üzerine bir arkadaşımın blog linkini bulabilirsiniz:


http://blogs.msdn.com/johan/archive/2007/11/13/getting-started-with-windbg-part-i.aspx


Dump analizinden bahsederken daha detaylandıracağım ama, DebugDiag'ın analiz aracını kullanırken de, kendiniz analiz yaparken de "sembol dosyaları"na ihtiyaç duyacaksınız. Bunların "public" versiyonlarını http://msdl.microsoft.com/download/symbols/ adresinden indirebilirsiniz.


CENK ISCAN

debugdiag2.GIF

Comments (3)

  1. Geliştirmiş olduğumuz uygulamalarda karşılaştığımız sorunları gidermek için analiz yaparken kullandığımız

  2. serdar says:

    cenk bey merhaba yapmak istediğim asp.net uygulamalrında sayfa üzerinde hata alındığında çıkan

    exception hatasını direk kodun neresinde handi cs dosyasında olduğunu bilmek

    bu konu benim istediğim şeymi ?

    ve resimler görünmüyor o yüzden konuyu anlayamadım

  3. CenkIscan says:

    Dump alarak hataların nerede oluştuğunu görebilirsiniz ama bunun en kolay yolu bu değildir. Yani sadece hatalarda daha fazla detay görmek için dump analizi öğrenmeye değmez bence. Uygulamanız debug modda ise, veya pdb dosyaları varsa zaten bu detayı görebilirsiniz.

    Ekran görüntüleri konusunu düzeltmeye çalışacağım, ama DebugDiag kurduğunuzda zaten buna gerek olmayacaktır. Bu arada benim bu yazım oldukça eski, şu anda DebugDiag 1.2 bulunuyor.

Skip to main content