DebugDiag isimli araçtan ve bunun nasıl ve ne amaçla kullanıldığından daha önceki bloglarımda bahsetmiştim. Bu defa sadece ne tür sorunlarda hangi adımları izleyerek dump toplamamız gerektiğini adım adım vereceğim. Hangi tür sorunda ne şekilde dump alınacağını bilmek çok önemlidir, çünkü, örneğin “crash” durumunda alınacak bir “hang” dump hiçbir işe yaramayacaktır. Bunun tersi de aynen doğrudur. Dolayısıyla, önce sorunumuzun ne olduğundan emin olup, ona uygun adımları izlemeliyiz.
1. "Crash" sorunları:Uygulamamız, yani IIS 6.0 ve 7.0 için w3wp.exe bir nedenle kendiliğinden kapanıyorsa, ve/veya olay günlüklerinde aşağıdaki kayıtlardan birini görüyorsak bu adımları uygulayarak dump toplamamız gerekecektir:
Event ID
Description
1009
A process serving application pool %1 was terminated unexpectedly. The process ID was %2. The process exit code was '0x%3.
1010
A process serving application pool %1 failed to respond to a ping. The process ID was %2.
1011
A process serving application pool %1 suffered a fatal communication error with the WWW service. The process ID was %2. The data field contains the error number.
“Crash” sorunu ortaya çıktığında, ilgili uygulamayı çoktan kaybetmiş oluruz. Bu nedenle, sorun oluşmadan önce aşağıdaki adımları uygulayarak bir kural yaratmamız gerekir. Bu kural ile DebugDiag, sorunun yeniden oluşmasını bekleyecek ve otomatik olarak dump alacaktır:
NOT: Eğer sadece belirli bir “application pool”un dumpını almak istiyorsak, dördüncü adımda “A specific IIS web application pool”u seçip, bir sonraki ekranda da o pool’u seçebilirsiniz. Böylece gereksiz yere tüm pool’ların dumpını almamış oluruz.
2. “First chance exception” dumpları:Nadiren de olsa, bazı “crash” senaryolarında bu adımlarla dump toplayamayabiliriz; veya topladığımız dump bize yeterli veriyi sağlayamayabilir. Böyle durumlarda, özellikle belirli bir hata durumda dump almak isteriz. Bunun için, yine sorun oluşmadan önce, şu adımları izleyerek bir kural yaratmamız gerekir:
NOT: “Crash” dump adımlarındaki not burada da geçerlidir. Yani duruma göre, dördüncü adımda “A specific IIS web application pool” seçmek isteyebilirsiniz.
3. “Hang” sorunları:“Hang” sorunlarında dump toplama işlemini, DebugDiag ile yine otomatize etmek mümkün olsa da, benim tercihim “manuel” dump toplamak yönündedir. “Hang” durumlarında dikkat edilecek bir husus da, tek dumpın bize yeterli bilgi sağlamayacak olmasıdır. Duruma göre, bir veya birkaç dakika arayla toplanmış en az 2-3 adet dump gerekecektir. Yukarıdaki iki tür sorundan farklı olarak, “hang” sorunlarında dump almak için sorunun oluşmasını beklemek zorundayız. Sorun oluştuğu anda:
4. Yüksek bellek kullanımı sorunları:Yüksek bellek kullanımı sorunlarında, uygulamamızın türüne göre farklı yöntemlerle dump alınması gerekir. .NET uygulamalarında, bellek kullanımı yükseldiğinde duruma göre birkaç dakika arayla “hang” dump almak gerekir. .NET dışındaki (unmanaged) uygulamalarda ise “Memory and Handle Leak” seçeneği ile bir kural yaratmak gerekecektir (aslında bu kural .NET uygulamalarında da işe yarayacaktır). Burada bunun için gerekli adımları vermeyeceğim; çünkü sorunun ortaya çıkış şekline bağlı olarak çok farklı ayarlar yapmak gerekecektir.
DebugDiag’la toplayacağımız dumplar, pek çok sorunun teşhisinde çok işe yarayacaktır, hatta bazı durumlarda tek teşhis yöntemi olacaktır. Ancak burada önemli olan ve asla unutmamak gereken şey, doğru şekilde alınmayan dumpların hiçbir faydası olmayacağıdır. Elbette doğru şekilde dump topladıktan sonra, bunların incelenmesi aşaması karşımıza çıkıyor ki, bu da başlı başına bir uzmanlık gerektirir. Bundan da ileride bahsedeceğim.
CENK ISCAN