Linux VDS’de bir işlem aniden kayboluyor, servis tekrar başlıyor veya gece çalışan rapor yarıda kalıyorsa bellek yetersizliği olasılıklardan biridir. Fakat tek başına kapanma, OOM tanısı değildir. Önce olayın saatini ve hangi işin çalıştığını kaydedin. Sürekli kaynak takibi için VDS izleme planı, olaydan çok sonra alınmış ekran görüntüsünden daha yararlı bir bağlam sunar.
OOM killer neyi ifade eder?
Linux Kernel bellek belgesi, sistem yeterli bellek geri kazanamadığında OOM killer mekanizmasının bir işlemi sonlandırarak sistemi korumaya çalışabileceğini açıklar. Bu genel davranış, belirli kapanışın nedenini tek başına kanıtlamaz. Yüksek toplam kullanım veya cache değeri de yeterli değildir; Linux RAM ve cache rehberindeki kullanılabilir bellek ayrımını hatırlayın.
Olay zamanındaki kayıtları arayın
Sistem yöneticisinden kapanış saatine ait kernel ve uygulama kayıtlarını birlikte incelemesini isteyin. Mesajda bellek yetersizliği, öldürülen işlem veya ilgili süreç bilgisi var mı? Tam satırı ve zaman bağlamını koruyun. Kayıt bulunmaması kesin olarak OOM olmadığı anlamına gelmeyebilir; saklama kapsamı ve erişim yetkisi sonucu etkiler. Kayıtları temizlemek veya sunucuyu hemen yeniden başlatmak ilk teşhis adımı değildir.
Aynı işin ne zaman başladığını, kaç paralel görev çalıştığını ve kullanılan veri boyutunu not edin. Örneğin gündüz tek rapor tamamlanırken gece birden fazla raporun aynı anda başlaması, farklı bir iş yükü senaryosudur. Bu gözlem ölçüm gerektirir; gerçek veri yokken belirli bir RAM miktarının yeterli olacağını söylemeyin. Test verisini üretim kayıtlarından ayırın.
Uygulama sınırı ile toplam kapasiteyi ayırın
Süreç veya hizmet için tanımlanan kaynak sınırları, toplam sunucu belleğinden ayrı olabilir. Linux süreç limitleri belgesi, /proc/PID/limits içindeki yumuşak ve sert sınırların okunmasını açıklar. Bu dosya tek başına tüm container ya da servis bellek politikasını göstermeyebilir. Yetkili yönetici gerçek süreç ve çalışma ortamını belirlemelidir; sınırları rastgele kaldırmayın.
Kalıcı çözümü iş yüküne göre seçin
Uygulama üreticisinin önerdiği eşzamanlılık, bellek ayarı ve sürüm düzeltmelerini değerlendirin. Otomatik yeniden başlama, yarım kalmış işin tekrar yazılması veya çift gönderim gibi riskler oluşturabilir. Yeniden deneme stratejisi uygulamanın iş mantığıyla birlikte planlanmalıdır. Kapasite ihtiyacı için VDS RAM seçimi rehberini kullanın; VDS paketini yükseltme kararını gerçek tüketim ve büyüme eğilimine dayandırın.
Destek kaydına olay zamanı, uygulama sürümü, aynı anda çalışan işler ve hassas bilgileri temizlenmiş kayıtları ekleyin. Koruma mekanizmasını kapatmak veya her programı en yüksek öncelikle korumak diğer hizmetleri riske atabilir. Önce hangi tüketimin ve hangi sınırın sorunu tetiklediğini bulmak daha kontrollü bir yoldur.
Tek bir örnek yerine tekrarlayan olaylar için basit bir çizelge tutun: işin adı, veri boyutu, eşzamanlı görevler ve görülen kapanış. Her yeni denemede aynı ağır işi sınırsızca çoğaltmayın. Üretim sistemini zorlayarak kanıt üretmek yerine mevcut kayıt ve ölçümleri kullanmak hem uygulama verisini korur hem de normal kullanım koşullarını daha doğru temsil eder.
Sıkça Sorulan Sorular
Program kapandıysa kesin OOM mu?
Hayır. Uygulama hatası, yönetici işlemi, servis politikası ve başka nedenler de olabilir; kayıtla doğrulayın.
Yüksek cache OOM kanıtı mı?
Hayır. Cache ile kullanılabilir bellek ayrı değerlendirilmelidir; olay zamanındaki kayıt ve iş yükü gerekir.
OOM korumasını kapatayım mı?
Bu genel bir çözüm değildir. Sistemin tamamını etkileyebilir; bellek tüketiminin nedeni ve sınırlar incelenmelidir.
RAM yükseltmek her zaman çözer mi?
Hayır. Bellek sızıntısı, kontrolsüz eşzamanlı iş veya yanlış uygulama sınırı varsa kapasite artışı yalnız sorunu erteleyebilir.