“No space left on device” hatasında ilk refleks büyük dosyaları silmek olabiliyor. Oysa uygulamanın yazdığı dosya sistemi, inode tüketimi ve açık dosyalar görülmeden yapılan temizlik hem zaman kaybettirebilir hem de gerekli veriyi silebilir. Önce hatanın hangi yolda oluştuğunu belirleyin.
Bir sunucuda kök dizinin boş olması, uygulamanın veri bölümünde yer bulunduğunu göstermez. Container, ayrı mount veya ağ dosya sistemi kullanılıyorsa uygulamanın gördüğü depolama alanı ayrıca kontrol edilmelidir. İncelemeyi mümkün olduğunca hatayı üreten süreçle aynı bağlamda yürütün.
Alan ve inode kullanımını ayrı okuyun
df -h /var
df -i /var
Buradaki /var örnektir; uygulamanın gerçekten yazdığı yolu kullanın. İlk sorgu dosya sistemi alanını, ikinci sorgu inode kullanımını gösterir. Dosya sisteminin inode yönetimi türüne göre değişir; görülen rakamları kullanılan dosya sisteminin özellikleriyle değerlendirin. Komut seçenekleri GNU df dokümanında yer alıyor.
Çok sayıda küçük dosya, toplam veri boyutu düşük görünse bile inode kapasitesini zorlayabilir. Önbellekler, kuyruk dizinleri ve başarısız işlem artıklarının birikmesi bu nedenle araştırmaya değer. Ancak yalnızca dosya sayısına bakarak bir dizinin içeriğini gereksiz kabul etmeyin.
Dosya sisteminde alan görünmesine rağmen yazma başarısızsa kullanıcı veya proje kotası, salt okunur bağlama durumu ve uygulamanın gerçek hata kodu da incelenmeli. Her yazma sorunu kapasite sorununa indirgenmemeli.
Taramayı sorunun olduğu bölümle sınırlayın
GNU araçları bulunan bir sistemde şu sorgu, /var altındaki ilk seviye alan dağılımını gösterir:
du -x -h --max-depth=1 /var
-x farklı dosya sistemlerine geçişi sınırlar. Büyük ağaçların taranması disk yükü oluşturabilir; yoğun saatlerde tüm sunucuyu taramak yerine şüpheli bölgeden başlayın. Yetki nedeniyle okunamayan dizinler varsa sonucu eksiksiz ölçüm gibi raporlamayın.
GNU du başvurusu, görünür dosya boyutu ile ayrılmış disk alanının farklı olabileceğini açıklıyor. Sparse dosyalar, paylaşılan bloklar ve dosya sistemi özellikleri karşılaştırmayı etkileyebilir. df ile du arasında fark görünmesi tek başına bozulma kanıtı değildir.
Silinmiş ama açık kalan dosyaları kontrol edin
Bir süreç dosyayı açık tutarken dosyanın adı silinmiş olabilir. Bu durumda süreç ilgili dosyayı bırakana kadar kullanılan alanın tamamı serbest kalmayabilir. lsof kurulu ve gerekli okuma yetkisi varsa şu kontrol yardımcı olur:
lsof +L1
Seçeneğin anlamını lsof projesinin başvurusundan kontrol edin. Çıktıda dosyayı tutan süreç ve ilgili dosya sistemi eşleştirilmelidir. Buradan doğrudan süreç öldürme kararına geçmeyin. Uygulamanın desteklediği log döndürme veya yeniden yükleme yöntemi varsa önce onu değerlendirin.
Temizliği tekrarını önleyecek şekilde planlayın
Müdahale öncesinde dosyaların sahibi, saklama süresi ve yedek durumu net olsun. Veritabanı dosyaları, işlem günlükleri ve kuyruk içerikleri uygulamanın kendi prosedürü dışında silinmemeli. Her değişiklikte kapsamı küçük tutun ve gerekiyorsa bakım penceresi açın.
Alan geri geldikten sonra büyüme hızını izleyin. Log rotasyonu çalışıyor mu, başarısız işler yeni dosya üretmeye devam ediyor mu, kapasite eşiğine yeniden ne zaman ulaşılacak? Kalıcı çözüm, boşalan gigabayt kadar yeniden dolmaya yol açan davranışın anlaşılmasına bağlıdır.
Yorumlar (0)
Henüz onaylanmış yorum yok.