Çöküş Dökümü: Süreç Neden Öldüğünü Nasıl Öğrenirsiniz?
Servis çalışıyordu, sonra durdu. Uygulama günlüğünde hiçbir hata yok — son satır normal bir işlemi anlatıyor. Sanki süreç cümlenin ortasında susmuş gibi. Bu tür sessiz ölümlerde cevap uygulama günlüğünde değil, sistemin kendi kayıtlarında ve döküm dosyalarındadır.
Bu yazı, çöken süreçlerin teşhisini ele alıyor.
Ölüm Türleri
| Neden | İz bırakır mı |
|---|---|
| Uygulama hatası | Günlüğe yazar |
| Bellek yetersizliği | Sistem kaydına yazar |
| Bölütleme hatası | Döküm üretebilir |
| Dışarıdan sonlandırma | Genellikle sessiz |
İkinci satır en sık karşılaşılan ve en yanlış teşhis edilen durumdur: bellek yetersizliği nedeniyle sonlandırılan bir süreç uygulama günlüğüne hiçbir şey yazamaz çünkü kendisi haberdar değildir — kayıt yalnızca sistem tarafında bulunur.
Bu yüzden geliştirici uygulamada hata arar ve bulamaz.
Doğru yer, çekirdek ve sistem kayıtlarıdır.
Orada hangi sürecin neden seçildiği açıkça yazar.
Sistem Kayıtlarını Okumak
- Çöküş zamanını belirleyin.
- O zaman aralığındaki sistem kayıtlarına bakın.
- Sonlandırma satırını arayın.
Üçüncü adım kesin cevabı verir: sistem, sonlandırdığı sürecin adını, kullandığı bellek miktarını ve neden seçildiğini ayrıntılı biçimde kaydeder — bu tek satır, günlerce sürebilecek bir araştırmayı bitirir.
Bu kayıtlar servis yöneticisi üzerinden de görüntülenebilir.
Zaman filtresi kullanmak aramayı hızlandırır.
Kayıt yoksa ölüm nedeni başka bir şeydir.
Servis Yöneticisi Kaydı
- Çıkış kodu kaydedilir.
- Sinyal bilgisi kaydedilir.
- Yeniden başlatma sayılır.
İkinci madde nedeni daraltır: süreç bir sinyalle mi yoksa kendi kararıyla mı sonlandı bilgisi, sorunun içeride mi dışarıda mı olduğunu anında ayırt ettirir — sinyalle ölen bir süreç kendi kodunda hata vermemiştir.
Bu ayrım araştırmanın yönünü belirler.
Üçüncü madde ise sorunun tekrarını gösterir.
Tek seferlik bir çöküş ile döngü farklı sorunlardır.
Döküm Dosyaları
| İçerik | Faydası |
|---|---|
| Bellek görüntüsü | O andaki durum |
| Çağrı yığını | Hangi kodda çöktü |
| Değişken değerleri | Hangi veriyle çöktü |
İkinci satır en değerli bilgidir: çağrı yığını, sürecin öldüğü anda hangi işlevin çalıştığını sırasıyla gösterir — bu, tekrar üretilemeyen çöküşlerde elinizdeki tek somut kanıttır.
Yorumlanmış dillerde bu bilgi genellikle günlüğe düşer.
Derlenmiş bileşenlerde ise döküm gerekir.
Görüntü işleme kütüphaneleri bu gruba girer.
Döküm Almayı Açmak
- Döküm boyutu sınırı kaldırılır.
- Kayıt yolu tanımlanır.
- Disk alanı ayrılır.
Üçüncü madde ihmal edilirse yeni bir sorun doğar: bellek görüntüsü sürecin kullandığı bellek kadar yer kaplar — birkaç gigabaytlık bir süreç, her çöküşte birkaç gigabaytlık dosya bırakır ve tekrarlayan çöküşler diski hızla doldurur.
Bu nedenle döküm sayısı sınırlanmalıdır.
Eski dökümler otomatik temizlenmelidir.
Sürekli açık bırakmak yerine sorun süresince açmak da bir seçenektir.
Dökümde Ne Var
- Bellekteki her şey.
- Şifreler ve anahtarlar dahil.
- Kullanıcı verileri dahil.
İkinci madde ciddi bir gizlilik riskidir: bir bellek dökümü, o anda bellekte bulunan veritabanı şifrelerini, oturum belirteçlerini ve kişisel verileri düz metin olarak içerir — bu dosyayı destek ekibine göndermek, tüm sırlarınızı paylaşmak demektir.
Döküm dosyaları kısıtlı izinlerle saklanmalıdır.
Dışarı paylaşılmadan önce içerik değerlendirilmelidir.
Analiz mümkünse kendi ortamınızda yapılmalıdır.
Yeniden Üretmek
| Bilgi | Neden gerekli |
|---|---|
| Çöküş saati | Kayıtları eşleştirmek |
| O anki istek | Tetikleyiciyi bulmak |
| Sistem yükü | Kaynak sorununu ayırmak |
İkinci satır çoğu vakayı çözer: çöküş anında işlenen isteği bulmak, sorunun belirli bir girdiden mi kaynaklandığını gösterir — aynı isteği test ortamında tekrarlamak çöküşü yeniden üretebilir.
İstek kimliği kullanan sistemlerde bu eşleştirme kolaydır.
Üçüncü satır ise yük kaynaklı çöküşleri ayırır.
Yalnızca yoğun saatlerde ölen bir süreç kaynak sorunu yaşıyordur.
Tekrarı Önlemek
- Otomatik yeniden başlatma kurun.
- Ama nedeni araştırın.
- Uyarı üretin.
İkinci madde önemli bir tuzağı işaret eder: otomatik yeniden başlatma çöküşü görünmez kılar — servis anında geri geldiği için kimse fark etmez ve altta yatan sorun aylarca sürer.
Bu, kısa vadede iyi uzun vadede kötü bir çözümdür.
Üçüncü madde bu körlüğü kaldırır.
Her beklenmedik yeniden başlatma kaydedilmeli ve sayılmalıdır.
Çöküş kayıtlarına ve sistem günlüklerine erişebilmek tam yönetici yetkisi gerektirir; sanal sunucu kiralama seçenekleri ile teşhis araçlarını sınırsız kullanabilirsiniz.
Sonuç
Sessizce ölen süreçlerin cevabı uygulama günlüğünde değildir: bellek yetersizliğiyle sonlandırılan bir süreç günlüğe hiçbir şey yazamaz çünkü kendisi haberdar değildir. Önce sistem kayıtlarına bakın, servis yöneticisinin kaydettiği sinyal bilgisiyle sorunun içeride mi dışarıda mı olduğunu ayırın ve döküm alacaksanız diski koruyun. Dökümleri paylaşırken dikkatli olun — içlerinde şifreler ve kişisel veriler düz metin olarak bulunur.
Sıkça Sorulan Sorular (SSS)
Süreç sessizce ölüyor, günlükte hiçbir şey yok?
Büyük olasılıkla bellek yetersizliğinden sonlandırılmıştır. Böyle bir süreç uygulama günlüğüne hiçbir şey yazamaz çünkü kendisi haberdar değildir; kayıt sistem tarafındadır ve orada hangi sürecin neden seçildiği ayrıntılı yazar.
Sinyal bilgisi neden önemli?
Sürecin bir sinyalle mi yoksa kendi kararıyla mı sonlandığını gösterir ve bu, sorunun içeride mi dışarıda mı olduğunu anında ayırt ettirir. Sinyalle ölen bir süreç kendi kodunda hata vermemiştir; araştırmanın yönü değişir.
Döküm almayı sürekli açık tutmalı mıyım?
Dikkatli olun. Bellek görüntüsü sürecin kullandığı bellek kadar yer kaplar; birkaç gigabaytlık bir süreç her çöküşte o kadar dosya bırakır ve tekrarlayan çöküşler diski hızla doldurur. Döküm sayısını sınırlayın ve eskilerini temizleyin.
Döküm dosyasını destek ekibine gönderebilir miyim?
Önce içeriğini değerlendirin. Bir bellek dökümü, o anda bellekte bulunan veritabanı şifrelerini, oturum belirteçlerini ve kişisel verileri düz metin olarak içerir. Mümkünse analizi kendi ortamınızda yapın ve dosyayı kısıtlı izinlerle saklayın.
