Kehabisan ruang adalah penyebab paling umum server berhenti bekerja tanpa ada niat jahat yang terlibat. Situs mengembalikan 500, basis data tidak bisa menulis, surat tidak keluar — dan sementara itu df -h melaporkan beberapa gigabita kosong. Mari kita telusuri ketiga kasus di mana hal itu terjadi, dan apa yang layak diketahui soal SMART.

Kasus satu: inode habis

Sebuah sistem berkas punya dua sumber daya terbatas: ruang untuk isi dan catatan tentang berkas. Yang kedua habis secara independen dari yang pertama:

df -h
df -i

Kalau IUse% pada perintah kedua bernilai 100 maka masalahnya adalah inode. Ruangnya ada, tetapi tidak satu berkas pun bisa dibuat, bahkan yang kosong sekalipun.

Pelakunya selalu itu-itu juga: jutaan berkas mungil. Sesi PHP di /var/lib/php/sessions yang pengumpulan sampahnya rusak. Cache aplikasi yang tak pernah dibersihkan. Antrean surat yang macet. Sebuah direktori gambar mini. Anda bisa menemukannya begini:

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

Perintah ini mendaftar direktori dengan berkas terbanyak. Pada sistem besar ia berjalan beberapa menit — itu normal.

Kasus dua: berkas terhapus dan ruangnya tidak kembali

Situasi yang lebih licik lagi. Seseorang menghapus log yang membengkak dengan rm, tetapi proses yang menulis ke situ masih memegangnya terbuka. Berkasnya tidak lagi ada di direktori, ruangnya masih terpakai, dan akan tetap begitu sampai prosesnya dinyalakan ulang.

sudo lsof +L1

Perintah ini menampilkan berkas dengan nol tautan di sistem berkas tetapi masih dipegang sebuah proses. Obatnya adalah menyalakan ulang atau memuat ulang proses itu dengan lembut, bukan berburu «ke mana perginya gigabita itu».

Dari sini muncul aturan: log yang membengkak tidak dihapus melainkan dipotong menjadi kosong, sehingga deskriptor yang terbuka tetap berguna:

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

Dan segera setelah itu siapkan rotasi — kalau tidak, semuanya akan terulang dalam sepekan.

Kasus tiga: log yang memakannya

Ruangnya pergi ke mana persisnya terlihat dengan menuruni tingkat demi tingkat:

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

Bendera -x menjaganya agar tidak melantur ke sistem berkas lain; tanpanya perhitungan merangkak ke /proc dan mount jaringan. Semua ini lebih nyaman dikerjakan di ncdu, kalau tersedia.

Para pemakan yang biasa:

  • journald. Satu perintah menyelesaikannya: journalctl --disk-usage. Ia dibatasi dengan baris SystemMaxUse=500M di /etc/systemd/journald.conf dan dibersihkan sekali dengan journalctl --vacuum-size=200M;
  • log perkakas keamanan. Suricata dengan konfigurasi bawaannya menulis tiga puluh jenis peristiwa dan tidak menyiapkan rotasi untuk dirinya sendiri — pada server sungguhan itu menghasilkan 15 GB dalam dua hari. Hal yang sama terjadi dengan audit.log dan dengan log debug di nginx;
  • cadangan yang ditulis ke disk yang sama dan tidak pernah dihapus;
  • cache apt — apt clean sesekali mengembalikan satu dua gigabita.

Sepatah dua kata soal /boot

Partisi kecil yang penuh oleh kernel lama. Ia sendiri tidak menumbangkan situs, tetapi ia menghentikan pembaruan sepenuhnya: kernel baru tidak akan terpasang, dan seluruh antrean paket macet di belakangnya. Diobati dengan apt autoremove --purge, dan dicegah dengan menyalakan penghapusan otomatis kernel yang tidak terpakai di pengaturan pembaruan otomatis.

SMART: atribut mana yang penting

Peringatan lebih dulu: pada server virtual SMART biasanya tidak tersedia — disknya virtual dan Anda tidak melihat disk fisik di bawahnya. Itu bukan kerusakan, datanya memang tidak ada. Semua yang berikut menyangkut server khusus dan perangkat keras Anda sendiri.

sudo smartctl -a /dev/sda

Baris SMART overall-health self-assessment test result: PASSED bukan alasan untuk tenang: ia tetap hijau praktis sampai drive-nya mati. Yang perlu dilihat adalah pencacah yang spesifik:

  • 5, Reallocated_Sector_Ct — sektor yang dialokasikan ulang. Bukan nol berarti drive sudah mulai merosot; bertambah seiring waktu berarti ganti tanpa menunda;
  • 197, Current_Pending_Sector — sektor yang tidak bisa dibaca dan menunggu keputusan. Yang paling mengkhawatirkan di antaranya: biasanya itu berarti sebagian data sudah tidak bisa dipulihkan;
  • 198, Offline_Uncorrectable — hal yang sama, sudah dipastikan lewat pemeriksaan;
  • SSD: Percentage Used / Media_Wearout_Indicator — daya tahan tulis yang sudah terpakai. Angka yang bisa diprediksi, dan itulah yang dipakai merencanakan penggantian.

Sebaliknya, suhu dan jam operasi dengan sendirinya tidak mengatakan apa-apa: sebuah drive dengan lima tahun masa jalan dan pencacah galat nol lebih andal daripada drive baru dengan angka 1 di atribut 197.

Makna pengawasan

Semua di atas adalah reaksi terhadap sesuatu yang sudah terjadi. Padahal baik disk yang terisi maupun keausan SSD sama-sama proses yang lambat dan sepenuhnya bisa diprediksi: grafik pemakaian selama dua pekan menunjukkan tanggal ruangnya habis jauh sebelum hal itu terjadi. Perbedaan antara «situs mati sejak pukul tiga pagi» dan «Kamis nanti log perlu dibersihkan» hanyalah soal apakah angka itu ada di depan mata Anda. Bagaimana tampilannya ketika dirangkai — lihat di halaman demo di bawah.