Yerin bitmesi, hiçbir kötü niyet olmadan bir sunucunun çalışmayı bırakmasının en sık görülen nedenidir. Site 500 döner, veritabanı yazmaz, posta çıkmaz — ve df -h bu arada birkaç gigabayt boş alan bildirir. Bunun olduğu üç durumu ve SMART hakkında bilinmeye değer olanı adım adım geçelim.

Birinci durum: inode’lar bitti

Bir dosya sistemi iki sınırlı kaynak tutar: içerik için yer ve dosyalara dair kayıtlar. İkincisi birincisinden bağımsız olarak tükenir:

df -h
df -i

İkinci komutta IUse% 100 ise sorun inode’lardır. Yer vardır, ama tek bir dosya oluşturulamaz, boş bir dosya bile.

Suçlular hep aynıdır: milyonlarca minik dosya. Çöp toplaması bozulmuş, /var/lib/php/sessions içindeki PHP oturumları. Hiç temizlenmeyen bir uygulama önbelleği. Takılmış bir posta kuyruğu. Bir küçük resim dizini. Onları şöyle bulabilirsiniz:

sudo find / -xdev -type f -printf '%h\n' 2>/dev/null | sort | uniq -c | sort -rn | head -20

Komut en çok dosyaya sahip dizinleri listeler. Büyük bir sistemde dakikalarca çalışır — bu normaldir.

İkinci durum: dosya silindi, yer geri gelmedi

Daha da sinsi bir durum. Birisi şişmiş bir günlüğü rm ile kaldırdı, ama ona yazan süreç onu hâlâ açık tutuyor. Dosya artık dizinde değildir, yer hâlâ doludur ve süreç yeniden başlatılana kadar öyle kalır.

sudo lsof +L1

Komut, dosya sisteminde sıfır bağlantısı olan ama bir sürecin hâlâ tuttuğu dosyaları gösterir. Çare, «gigabaytlar nereye gitti» avı değil, o sürecin yeniden başlatılması ya da nazikçe yeniden yüklenmesidir.

Buradan kural çıkar: şişmiş bir günlük silinmez, kısaltılır; böylece açık tanımlayıcı kullanılabilir kalır:

sudo truncate -s 0 /var/log/huge.log

Ve hemen ardından döndürme kurun — yoksa bütün bu iş bir hafta içinde tekrarlanır.

Üçüncü durum: günlükler yedi

Yerin tam olarak nereye gittiği, kademe kademe inerek görünür:

sudo du -x -h --max-depth=1 / | sort -h
sudo du -x -h --max-depth=1 /var | sort -h

-x bayrağı başka dosya sistemlerine dolaşmasını engeller; o olmadan sayım /proc içine ve ağ bağlarına sürünür. Bütün bunlar, varsa ncdu içinde daha rahattır.

Alışıldık oburlar:

  • journald. Tek bir komut meseleyi çözer: journalctl --disk-usage. /etc/systemd/journald.conf içindeki SystemMaxUse=500M satırıyla sınırlanır ve journalctl --vacuum-size=200M ile bir kez temizlenir;
  • güvenlik aracı günlükleri. Suricata standart yapılandırmasıyla otuz kadar olay türü yazar ve kendisi için hiçbir döndürme kurmaz — gerçek bir sunucuda bu, iki günde 15 GB üretti. Aynısı audit.log ile ve nginx’teki hata ayıklama günlükleriyle de olur;
  • aynı diske yazılan ve hiç silinmeyen yedekler;
  • apt önbelleği — apt clean arada bir birkaç gigabayt geri verir.

/boot hakkında bir not

Eski çekirdeklerle dolan küçük bir bölüm. Siteyi kendi başına düşürmez, ama güncellemeleri tam anlamıyla durdurur: yeni çekirdek kurulmaz ve bütün paket kuyruğu onun arkasında takılır. apt autoremove --purge ile iyileşir, otomatik güncelleme ayarlarında kullanılmayan çekirdeklerin otomatik silinmesi açılarak önlenir.

SMART: hangi öznitelikler önemli

Önce bir uyarı: sanal bir sunucuda SMART genellikle kullanılamaz — disk sanaldır ve altındaki fiziksel diski görmezsiniz. Bu bir arıza değildir, yalnızca veri yoktur. Bundan sonrası adanmış sunucular ve kendi donanımınızla ilgilidir.

sudo smartctl -a /dev/sda

SMART overall-health self-assessment test result: PASSED satırı rahatlamak için bir gerekçe değildir: sürücü ölene kadar pratikte yeşil kalır. Bakılması gereken şey belirli sayaçlardır:

  • 5, Reallocated_Sector_Ct — yeniden atanmış sektörler. Sıfır olmaması sürücünün çoktan bozulmakta olduğu anlamına gelir; zamanla artması gecikmeden değiştirin demektir;
  • 197, Current_Pending_Sector — okunamayan ve karar bekleyen sektörler. Hepsinin içinde en endişe vericisi: genellikle verinin bir kısmının çoktan kurtarılamaz olduğu anlamına gelir;
  • 198, Offline_Uncorrectable — aynısının bir kontrolle doğrulanmış hali;
  • SSD: Percentage Used / Media_Wearout_Indicator — tüketilmiş yazma dayanıklılığı. Öngörülebilir bir rakamdır ve değişim buna göre planlanır.

Buna karşılık sıcaklık ve çalışma saatleri tek başlarına hiçbir şey söylemez: beş yıllık çalışma süresi ve sıfır hata sayacı olan bir sürücü, 197 özniteliğinde 1 olan yeni bir sürücüden daha güvenilirdir.

İzlemenin anlamı

Yukarıdakilerin tamamı çoktan olmuş bir şeye verilen tepkidir. Oysa hem dolan bir disk hem de SSD aşınması yavaş, tümüyle öngörülebilir süreçlerdir: iki haftalık bir doluluk grafiği, yerin biteceği tarihi daha çok önceden gösterir. «Site gecenin üçünden beri kapalı» ile «perşembe günü günlükleri temizlemek gerek» arasındaki fark, rakamın gözünüzün önünde olmasından ibarettir. Bunun toplanmış hali aşağıdaki demo sayfasında.