Sunucuda disk doldu: Suçluyu bulma ve alan boşaltma

Site açılmıyor, MySQL Disk full hatası veriyor veya SSH oturum dosyası yazamadığı için girişe izin vermiyor. Öncelikle şunu kabul edin: Hangi dizinin alanı tükettiğini bilmeden yapılan her silme işlemi kumar oynamaktır. Yanlış dizinde yapılan hatalı bir rm -rf, hem siteyi hem de yedeği çökertir. Bu yüzden işlem sırası önemlidir.

Önce df, sonra du; tersi değil

Hangi mount'un dolduğunu görmek için df -h ile başlayın. / bölümü doluysa ancak /home sağlamsa, aramayı o dizin ağacıyla sınırlayın. Çoğu kişinin gözden kaçırdığı bir nokta: df -i komutunu da çalıştırın. Disk alanı boş olabilir ancak inode tükenmiş olabilir.

df -h
df -i
du -xhd1 / 2>/dev/null | sort -h

du komutundaki -x bayrağı, dosya sistemi sınırını aşmamasını sağlar; bu olmadan, dizin içinde bir NFS veya bind mount varsa sayılar anlamsız hale gelir. -d1 bir seviye derinlik verir ve sort -h en büyükleri listenin sonuna getirir. Şüpheli klasörü bulduktan sonra, dosyaya ulaşana kadar aynı komutu o klasörde tekrarlayın.

ncdu, du'dan daha hızlı yanıt verir

Yoğun trafikli sunucularda, du milyonlarca dosya üzerinde birkaç dakika sürer ve disk I/O'sunu tüketir. ncdu dizin ağacını bir kez indeksler ve sonra yön tuşlarıyla gezersiniz. Kurulu değilse, dağıtımın deposundan kurun:

ncdu -x /var

Çıktıda, d ile dosya silersiniz ve g ile yüzde ve ham boyut arasında geçiş yaparsınız. Pratik bir uyarı: ncdu yalnızca dosya sisteminde görüneni görür. Açık silinmiş dosyaları ve derin dizinlerdeki gizli dosyaları ayrıca avlamanız gerekir.

Silinmiş ama hâlâ alan tüketen dosya

Bu en klasik tuzaktır. Logu rm ile silersiniz, df hâlâ doludur ve du içinde hiçbir dosya bulunamaz. Nedeni basittir: nginx veya PHP-FPM gibi bir süreç hâlâ o dosyanın file descriptor'ını açık tutuyordur ve kernel, o kapanana kadar blokları serbest bırakmaz. lsof ile bulun:

lsof +L1
lsof -nP | grep deleted

lsof +L1 çıktısı, link count'u sıfırlanmış dosyaları gösterir. Son sütun serbest bırakılacak boyutu verir. Çözüm, dosyayı silmek değil; o servisi yeniden başlatmaktır. Eğer nginx ise, systemctl reload nginx yeterli değildir çünkü master süreç dosyayı açık tutuyordur; systemctl restart nginx gereklidir. Yeniden başlatmadan önce konfigürasyonun sağlam olduğundan emin olun, aksi halde servis açılmaz ve şimdi iki sorununuz olur.

Burada hata yapıyorlar

Ticket'larda en sık gördüğüm hata şudur: Birisi access.log'u rm ile siler, df değişmez ve "disk bozulmuş" sonucuna varır. Aslında web sunucusu süreci dosyayı açık tutuyordur. Belirtisi tam olarak budur: du log klasöründe küçük bir sayı gösterir ancak df aynı önceki yüzdeyi verir. Doğru yol, silmek değil truncate etmektir:

truncate -s 0 /var/log/nginx/access.log

Bu komut dosyayı yerinde tutar, inode'u korur ve süreç yeniden başlatma olmadan yazmaya devam eder. Döngüsel loglar için, logrotate'ı copytruncate ile yapılandırın ki bu sorun tekrarlanmasın.

Alan değil, inode tükendiğinde

Eğer df -h %40 boş diyorsa ancak df -i %100'deyse, sorun başka yerdedir. Bu durum, milyonlarca küçük dosyanız olduğunda ortaya çıkar: PHP session'ları, cache dosyaları, e-posta kuyruğu veya /var/spool'da birikmiş spam. Disk alanı işe yaramaz çünkü inode tükenmiştir. Bu komutla suçluyu bulun:

for d in /var/* /home/*; do echo "$(find $d -xdev 2>/dev/null | wc -l) $d"; done | sort -n

Süresi dolmuş session'ları temizlemek genellikle birkaç milyon inode serbest bırakır. Küçük dosya sayısı yapısal olarak yüksekse, geçici çözüm periyodik temizliktir ve gerçek çözüm, o veriyi daha fazla inode'a sahip bir dosya sistemine taşımak veya session için Redis kullanmaktır.

Araçların karşılaştırması; hangisini ne zaman çalıştırmalıyız

Mantıklı sıra şudur: Üst düzey teşhis için df -h ve df -i, sonra dizini bulmak için ncdu ve sayılar birbiriyle uyuşmadığında lsof +L1. Bu üç adımdan sonra hâlâ alan bulunamazsa, sorun muhtemelen başka bir katmandadır ve yazma yapan servisleri incelemeye geçmelisiniz.

Tekrarı önleme; sadece boşaltma değil

Alan boşaltmak işin yarısıdır. Kökü kapatmazsanız, iki hafta sonra aynı ticket'ı açarsınız. Üç pratik iş:

• Loglar için yalnızca günlük rotasyon değil, belirli maxsize ve rotate ile logrotate yapılandırın.
• WordPress uploads klasörü ve yedek klasörü için df uyarısı koyun; örneğin %85'in üzerinde size e-posta gönderen bir cron.
• Eski yedekleri aynı sunucuda tutmayın. Dolan aynı diskteki yedek, yedek değildir.

WordPress siteniz varsa, bu küçük dosyaların büyük kısmı eklentilerden ve cache'ten gelir. Bir WordPress eklenti denetimi genellikle hiçbir şey kaybetmeden birkaç gigabayt ve yüz binlerce gereksiz dosyayı siler. Yüksek trafikli siteler için, logları ve session'ları bağımsız bir bölüme ayırmak, tüm sunucunun çökmesini engeller. Hâlâ tek bölümlü paylaşımlı bir sunucuda çalışıyorsanız, ayrı bölümlendirmeye sahip Linux hosting bu riski azaltır.

Daha fazla komut ve servis yapılandırması için, ServerNet'in dokümantasyon ve bilgi bankası iyi bir kaynaktır. Ve bu incelemeyi kendi sitenizde yapmak istiyorsanız, ücretsiz araçlar hızlı bir başlangıç noktasıdır.

Sık sorulan sorular

Dosyayı sildikten sonra neden df hâlâ boş alan göstermiyor?

Çünkü bir süreç o dosyayı açık tutuyordur ve kernel, file descriptor kapanana kadar blokları serbest bırakmaz. lsof +L1 ile süreci bulun ve o servisi yeniden başlatın. Log dosyasını boşaltmak istiyorsanız, rm yerine truncate -s 0 kullanın.

df -h ve df -i arasındaki fark nedir ve hangisi daha önemli?

df -h kullanılan alan boyutunu gösterir ve df -i kullanılan inode sayısını. İkisi de önemlidir. Alan boşsa ancak inode %100'deyse, yeni dosya oluşturamazsınız ve tıpkı disk gerçekten doluyken olduğu gibi No space left on device gibi hatalar alırsınız.

Hangi klasörün diski doldurduğunu nasıl anlarım?

du -xhd1 / ile kökten başlayın ve en büyük klasörü seçin, sonra dosyaya ulaşana kadar aynı komutu onun içinde tekrarlayın. Dosya sayısı fazlaysa, ncdu -x /var daha hızlı ve kolaydır çünkü bir kez indeksler.

Logları rm ile silmek güvenli mi?

Hayır, eğer servis o dosyaya yazıyorsa. Silme, dosyanın du görünümünden kaybolmasına neden olur ancak alan serbest bırakılmaz ve servis isimsiz dosyaya yazmaya devam eder. Doğru yol, dosyayı truncate etmek veya copytruncate seçeneğiyle logrotate kullanmaktır.