Server Solusi – Kamu mungkin pernah menemukan kondisi ketika VPS masih memiliki ruang penyimpanan beberapa gigabyte, tetapi website tiba-tiba gagal membuat file baru. Proses upload berhenti, aplikasi tidak bisa menyimpan session, database mengalami kendala saat membuat temporary file, atau perintah tertentu menampilkan pesan:

No space left on device

Hal yang membingungkan, ketika diperiksa menggunakan df -h, kapasitas disk justru masih terlihat cukup longgar.

Kondisi seperti ini tidak selalu menandakan bahwa kapasitas penyimpanan VPS benar-benar habis. Ada kemungkinan filesystem sudah kehabisan inode, yaitu sumber daya yang digunakan Linux untuk merepresentasikan file dan direktori.

Masalah ini cukup penting diperhatikan, terutama pada VPS yang menjalankan website dengan banyak file kecil, seperti WordPress, aplikasi PHP, sistem caching, email hosting, dan layanan berbasis container.

Dalam troubleshooting seperti ini, saya lebih menyarankan memeriksa penggunaan inode terlebih dahulu sebelum memutuskan untuk menambah kapasitas disk atau menghapus file berukuran besar.

Mengapa VPS Kehabisan Inode Padahal Disk Masih Kosong?

VPS dapat kehabisan inode ketika jumlah file dan direktori yang tersimpan pada sebuah filesystem sudah mencapai batas inode yang tersedia.

Inode berbeda dengan kapasitas disk. Disk space mengukur kapasitas penyimpanan data, sedangkan inode berkaitan dengan jumlah objek filesystem yang dapat direpresentasikan.

Sebagai contoh, sebuah VPS memiliki kapasitas disk 100 GB, tetapi filesystem hanya menyediakan 1 juta inode. Jika aplikasi menghasilkan jutaan file kecil, inode bisa habis meskipun total ukuran seluruh file masih jauh di bawah 100 GB.

Untuk memastikan kondisi tersebut, jalankan:

df -hdf -i

Perintah pertama memeriksa penggunaan kapasitas disk, sedangkan perintah kedua memeriksa penggunaan inode.

Jika kolom IUse% menunjukkan 100%, sementara Use% pada pemeriksaan kapasitas disk masih rendah, kemungkinan besar kamu sedang menghadapi masalah inode exhaustion.

Solusinya bukan langsung menambah kapasitas disk, melainkan menemukan direktori yang menghasilkan terlalu banyak file dan membersihkan file yang memang sudah tidak dibutuhkan.

Memahami Perbedaan Inode dan Kapasitas Disk

Sebelum melakukan perbaikan, ada baiknya memahami mengapa kedua sumber daya ini bisa habis secara terpisah.

Baca JugaCara Mengatasi Out of Memory di Linux VPS

Dalam filesystem Linux, inode merupakan struktur data yang menyimpan informasi mengenai objek filesystem, seperti:

• Tipe file.
• Hak akses atau permission.
• Pemilik file.
• Ukuran file.
• Timestamp.
• Referensi ke lokasi data pada filesystem.

Nama file dan struktur direktori digunakan untuk menghubungkan sebuah nama dengan inode yang bersangkutan.

Sederhananya, kapasitas disk menentukan seberapa banyak data yang dapat disimpan, sedangkan inode membatasi jumlah objek filesystem yang dapat dibuat.

Perhatikan ilustrasi berikut:

Angka pada tabel hanya ilustrasi untuk memperlihatkan bahwa penggunaan disk dan inode tidak selalu berjalan beriringan.

Mengapa file kecil bisa menghabiskan inode?

Misalnya sebuah aplikasi membuat 500.000 file cache dengan ukuran rata-rata 2 KB.

Total ukuran data yang dihasilkan kurang lebih:

500.000 x 2 KB = 1.000.000 KB

Artinya, file tersebut hanya membutuhkan sekitar 1 GB ruang data, tetapi memerlukan ratusan ribu inode.

Inilah alasan mengapa direktori cache, session, temporary file, dan file hasil proses aplikasi perlu diperhatikan ketika VPS mengalami inode exhaustion.

Gejala VPS Mengalami Inode Exhaustion

Ada beberapa gejala yang dapat membantu kamu mengenali masalah ini.

Muncul error No space left on device

Pesan berikut merupakan salah satu indikasi yang perlu diperiksa:

No space left on device

Pesan tersebut dapat muncul ketika aplikasi mencoba membuat file, direktori, socket, atau objek filesystem lainnya.

Namun, pesan ini tidak secara otomatis membuktikan bahwa inode sudah habis. Kapasitas block storage, quota, dan filesystem lain juga perlu diperiksa.

Website gagal melakukan upload

Aplikasi website mungkin tidak dapat menyimpan gambar, dokumen, attachment, atau file hasil proses upload.

Pada WordPress, misalnya, masalah dapat terlihat ketika pengguna mencoba mengunggah gambar melalui Media Library.

PHP gagal membuat session atau temporary file

Aplikasi berbasis PHP dapat mengalami kegagalan ketika mencoba membuat session baru atau menulis temporary file.

Gejala yang mungkin muncul antara lain:

session_start(): Failed to create session

Pesan tersebut merupakan contoh kemungkinan gejala, bukan pesan yang pasti muncul pada semua kasus inode penuh.

Baca JugaLinux Server Load Average Tinggi Padahal Trafik Rendah? Ini Cara Mengeceknya

Cron job dan aplikasi gagal membuat file

Cron job yang menghasilkan laporan, backup, cache, atau temporary file juga dapat gagal berjalan.

Jika masalah terjadi pada filesystem yang digunakan oleh aplikasi tersebut, proses penulisan file bisa terhenti.

Proses instalasi software mengalami kegagalan

Package manager dan installer aplikasi dapat mengalami error ketika membutuhkan pembuatan file atau direktori baru.

Pada kondisi tertentu, proses instalasi bahkan dapat terhenti sebelum selesai.

Penyebab Inode VPS Cepat Habis

Tidak semua kasus inode penuh disebabkan oleh file berukuran kecil. Ada beberapa sumber yang perlu diperiksa.

Cache aplikasi menumpuk

Aplikasi web sering menghasilkan cache untuk mempercepat pemrosesan halaman.

Masalah muncul ketika cache tidak memiliki mekanisme pembersihan yang efektif. Jika setiap request menghasilkan file cache baru dan file lama tidak pernah dihapus, jumlah inode dapat terus bertambah.

Direktori yang perlu diperiksa antara lain:

/var/cache//var/www//home/*/public_html//tmp/

Lokasi sebenarnya bergantung pada aplikasi dan konfigurasi server.

Session PHP tidak pernah dibersihkan

PHP dapat menyimpan session dalam bentuk file pada direktori tertentu.

Jika session lama tidak dibersihkan secara efektif, jumlah file session dapat bertambah.

Pada sebagian sistem, session disimpan di:

/var/lib/php/sessions/

Namun, jangan menganggap lokasi tersebut selalu digunakan. Periksa konfigurasi PHP terlebih dahulu.

Log aplikasi menghasilkan terlalu banyak file

Aplikasi yang membuat log terpisah untuk setiap request, pengguna, proses, atau tanggal dapat menghasilkan banyak file.

Contohnya adalah aplikasi yang menyimpan log berdasarkan tanggal:

application-2026-10-01.logapplication-2026-10-02.logapplication-2026-10-03.log

Pola tersebut tidak selalu bermasalah. Namun, jika setiap proses menghasilkan banyak file tambahan tanpa mekanisme rotasi atau retensi, penggunaan inode dapat meningkat.

File temporary tidak dibersihkan

Direktori temporary sering digunakan oleh aplikasi untuk menyimpan file sementara.

Contohnya:

/tmp//var/tmp/

File sementara yang tertinggal dapat terus menggunakan inode, terutama ketika aplikasi tidak memiliki proses cleanup yang baik.

WordPress menghasilkan terlalu banyak file

Pada server hosting, instalasi WordPress dapat menghasilkan banyak file dari:

Baca JugaCara Mengatasi Permission Denied Saat SSH di Linux

• Plugin caching.
• Thumbnail gambar.
• Backup otomatis.
• File hasil optimasi gambar.
• File temporary plugin.
• Session dan cache aplikasi.

Jika satu VPS menjalankan banyak website, akumulasi file dari seluruh instalasi dapat menjadi signifikan.

Container menghasilkan banyak file

Docker dan aplikasi berbasis container juga perlu diperiksa.

File log container, temporary data, cache build, serta file pada writable layer dapat meningkatkan penggunaan inode.

Jangan langsung menjalankan perintah penghapusan Docker sebelum memeriksa container, volume, image, dan kebutuhan aplikasi yang sedang berjalan.

Cara Mendiagnosis Inode VPS Penuh

Pada bagian ini, kita mulai memeriksa filesystem secara bertahap.

Contoh perintah menggunakan GNU/Linux dengan utilitas standar seperti df, find, du, dan sort. Perintah tertentu dapat sedikit berbeda pada distribusi Linux atau versi utilitas yang digunakan.

Langkah 1: Periksa penggunaan disk dan inode

Jalankan:

df -h

Perintah ini menampilkan kapasitas filesystem dalam format yang lebih mudah dibaca.

Perhatikan kolom:

• Size: kapasitas filesystem.
• Used: ruang yang sudah digunakan.
• Avail: ruang yang masih tersedia.
• Use%: persentase penggunaan disk.

Selanjutnya, jalankan:

df -i

Perhatikan kolom berikut:

• Inodes: jumlah inode yang tersedia.
• IUsed: jumlah inode yang telah digunakan.
• IFree: jumlah inode yang masih tersedia.
• IUse%: persentase penggunaan inode.

Contoh ilustrasi kondisi inode penuh:

Filesystem     Inodes   IUsed   IFree IUse%/dev/vda1     1000000 1000000       0  100%

Jika hasil pemeriksaan menunjukkan kondisi seperti ini, filesystem tersebut sudah tidak memiliki inode bebas.

Langkah berikutnya: cari tahu direktori mana yang menggunakan inode paling banyak.

Langkah 2: Identifikasi filesystem yang bermasalah

Jangan langsung melakukan pencarian dari seluruh direktori root.

Periksa terlebih dahulu lokasi filesystem yang digunakan website:

df -hTdf -iT

Opsi -T menampilkan tipe filesystem, misalnya ext4 atau XFS.

Kemudian, tentukan filesystem tempat direktori website berada:

findmnt -T /var/www

Jika website berada di /home, gunakan:

findmnt -T /home

Mengapa pemeriksaan ini penting?

Sebuah VPS dapat memiliki beberapa filesystem atau mount point terpisah. Misalnya, /, /home, dan /var bisa berada pada filesystem yang berbeda.

Jika inode /home habis, membersihkan file pada /tmp belum tentu membantu karena keduanya mungkin menggunakan filesystem berbeda.

Baca JugaCara Mengatasi RAM VPS Penuh: Diagnosis dan Solusi Linux

Langkah 3: Cari direktori dengan penggunaan inode terbesar

GNU du menyediakan opsi --inodes untuk memperkirakan penggunaan inode berdasarkan direktori.

Jalankan:

sudo du --inodes -x -d 2 /var 2>/dev/null | sort -n

Penjelasan:

• sudo: memberikan akses pemeriksaan terhadap direktori yang membutuhkan hak administrator.
• du: menghitung penggunaan sumber daya direktori.
• --inodes: menampilkan jumlah inode, bukan ukuran data.
• -x: membatasi pencarian pada filesystem yang sama.
• -d 2: membatasi kedalaman direktori hingga dua tingkat.
• 2>/dev/null: menyembunyikan pesan error permission.
• sort -n: mengurutkan hasil berdasarkan angka.

Jika direktori /var bukan lokasi filesystem yang bermasalah, sesuaikan path dengan hasil pemeriksaan sebelumnya.

Sebagai contoh, untuk memeriksa direktori website:

sudo du --inodes -x -d 3 /var/www 2>/dev/null | sort -n

Perhatikan direktori dengan angka inode paling besar.

Kamu mungkin menemukan direktori seperti:

/var/www/example.com/wp-content/cache/var/www/example.com/wp-content/uploads/var/www/example.com/wp-content/upgrade

Path tersebut hanya contoh. Jangan langsung menghapus isinya sebelum mengetahui fungsi direktori tersebut.

Langkah 4: Hitung jumlah file pada direktori yang dicurigai

Setelah menemukan direktori dengan penggunaan inode tinggi, lakukan pemeriksaan lebih spesifik.

Misalnya:

sudo find /var/www/example.com/wp-content/cache \-xdev -type f | wc -l

Perintah tersebut menghitung jumlah file reguler di dalam direktori cache beserta subdirektorinya.

Jika ingin memeriksa jumlah direktori:

sudo find /var/www/example.com/wp-content/cache \-xdev -type d | wc -l

Ingat, inode tidak hanya digunakan oleh file reguler. Direktori dan beberapa jenis objek filesystem lainnya juga menggunakan inode.

Karena itu, jumlah file yang ditemukan dengan -type f bukan keseluruhan penggunaan inode.

Langkah 5: Periksa file berdasarkan direktori asal

Jika ingin mengetahui direktori mana yang menghasilkan banyak file, kamu dapat menjalankan:

sudo find /var/www/example.com/wp-content/cache \-xdev -type f -printf '%h\n' |sort |uniq -c |sort -nr |head -20

Perintah tersebut mengelompokkan file berdasarkan direktori induknya, kemudian menampilkan 20 direktori dengan jumlah file terbanyak.

Hasil ini dapat membantu membedakan apakah file menumpuk pada satu subdirektori atau tersebar di banyak lokasi.

Perlu diperhatikan bahwa proses pencarian dapat memerlukan waktu dan I/O cukup besar jika filesystem memiliki jutaan file.

Langkah 6: Periksa quota pengguna jika menggunakan hosting

Pada VPS dengan konfigurasi quota, inode dapat dibatasi berdasarkan pengguna atau grup.

Kondisi ini berbeda dengan inode filesystem yang benar-benar habis.

Untuk memeriksa quota pengguna, gunakan:

quota -s -u username

Ganti username dengan akun yang ingin diperiksa.

Jika menggunakan quota filesystem, administrator juga dapat memeriksa laporan quota dengan:

sudo repquota -a

Perintah tersebut bergantung pada konfigurasi dan dukungan quota di sistem.

Jika quota sudah mencapai batas, tetapi df -i masih menunjukkan inode tersedia, masalahnya mungkin berada pada batas quota pengguna, bukan kapasitas inode keseluruhan filesystem.

Cara Mengatasi VPS Kehabisan Inode

Setelah menemukan sumber penggunaan inode, pilih solusi berdasarkan hasil diagnosis.

Saya menyarankan memulai dari pembersihan file yang benar-benar tidak diperlukan. Jangan langsung melakukan perubahan pada filesystem atau menghapus direktori aplikasi secara massal.

Solusi 1: Bersihkan cache aplikasi yang sudah tidak diperlukan

Jika hasil diagnosis menunjukkan bahwa cache merupakan penyebab utama, periksa apakah aplikasi menyediakan mekanisme pembersihan cache sendiri.

Untuk WordPress, misalnya, gunakan fitur purge cache dari plugin caching yang digunakan.

Jika kamu mengelola cache melalui command line atau direktori khusus, pastikan path tersebut memang merupakan direktori cache dan bukan penyimpanan data penting.

Contoh menghapus isi direktori cache yang sudah diverifikasi:

sudo find /path/ke/cache \-mindepth 1 -maxdepth 1 -exec rm -rf -- {} +

Perhatian: perintah ini menghapus seluruh isi langsung direktori yang ditentukan, termasuk subdirektorinya.

Jangan menjalankannya sebelum memastikan path benar, isi direktori memang boleh dihapus, dan aplikasi tidak menyimpan data permanen di sana.

Setelah pembersihan, periksa kembali:

df -i

Jika persentase penggunaan inode turun, pembersihan tersebut berhasil membebaskan sebagian inode.

Solusi 2: Bersihkan session PHP yang sudah kedaluwarsa

Jika direktori session PHP menjadi sumber masalah, jangan langsung menghapus seluruh file session.

Menghapus session yang masih aktif dapat menyebabkan pengguna kehilangan status login atau sesi aplikasi.

Pertama, periksa lokasi penyimpanan session:

php -i | grep session.save_path

Perlu diingat bahwa output dari CLI bisa berbeda dengan konfigurasi PHP-FPM atau PHP pada web server.

Periksa juga konfigurasi yang digunakan oleh pool PHP-FPM terkait.

Jika session memang disimpan sebagai file, gunakan mekanisme garbage collection PHP atau kebijakan cleanup yang sesuai.

Untuk sistem yang menggunakan systemd-tmpfiles, periksa konfigurasi terkait sebelum menjalankan pembersihan:

systemd-tmpfiles --cat-config

Perintah ini membantu melihat konfigurasi tmpfiles yang digabungkan oleh systemd.

Jangan membuat aturan penghapusan session secara sembarangan. Pastikan hanya file yang benar-benar sudah kedaluwarsa yang dibersihkan.

Solusi 3: Perbaiki pengelolaan log aplikasi

Jika penggunaan inode berasal dari banyak file log, periksa mekanisme log rotation.

Pada Linux, logrotate dapat digunakan untuk mengelola rotasi dan retensi log.

Periksa konfigurasi:

sudo cat /etc/logrotate.conf

Lihat juga konfigurasi tambahan:

sudo ls -lah /etc/logrotate.d/

Jika aplikasi menghasilkan file log sendiri, pastikan konfigurasi rotasinya sesuai dengan pola nama dan lokasi file log aplikasi tersebut.

Kamu dapat menguji konfigurasi logrotate menggunakan:

sudo logrotate -d /etc/logrotate.conf

Opsi -d menjalankan mode debug tanpa melakukan perubahan pada file log.

Jangan menggunakan mode paksa sebelum memahami dampaknya terhadap proses aplikasi yang sedang menulis log.

Solusi 4: Bersihkan cache package manager

Pada VPS berbasis Debian atau Ubuntu, cache paket APT dapat diperiksa dan dibersihkan menggunakan:

sudo apt clean

Perintah ini menghapus file paket yang tersimpan dalam cache APT.

Namun, jangan berharap perintah tersebut selalu menyelesaikan inode exhaustion. Dampaknya bergantung pada jumlah file cache yang tersedia.

Untuk memeriksa ulang:

df -i

Jika menggunakan distribusi berbasis RHEL, mekanisme pembersihan cache mengikuti package manager yang digunakan, seperti DNF.

Solusi 5: Periksa file Docker dan container

Jika VPS menggunakan Docker, periksa penggunaan ruang penyimpanan terlebih dahulu:

docker system df

Perintah tersebut menampilkan penggunaan disk oleh image, container, volume, dan build cache.

Untuk melihat container yang berjalan:

docker ps -a

Jika build cache memang tidak dibutuhkan, kamu dapat mempertimbangkan:

docker builder prune

Perintah tersebut membersihkan build cache yang tidak lagi digunakan.

Untuk membersihkan resource Docker lainnya, gunakan perintah prune sesuai kebutuhan dan periksa daftar resource yang akan dihapus.

Penting: jangan menggunakan docker system prune --volumes secara sembarangan. Volume dapat berisi database, upload pengguna, atau data permanen aplikasi.

Pastikan backup tersedia sebelum membersihkan resource yang berpotensi mengandung data penting.

Solusi 6: Evaluasi quota inode pengguna

Jika pemeriksaan menunjukkan quota pengguna sudah mencapai batas, solusinya bukan selalu menghapus file dari seluruh VPS.

Administrator perlu mengevaluasi:

• Batas inode pengguna.
• Jumlah file yang dimiliki akun.
• Kebijakan quota hosting.
• Apakah batas tersebut memang sesuai dengan kebutuhan aplikasi.

Jika menggunakan panel hosting, periksa pengaturan quota pada panel tersebut.

Jangan mengubah konfigurasi quota tanpa memahami kebijakan penyimpanan dan pembagian resource yang berlaku.

Solusi 7: Evaluasi filesystem jika inode selalu habis

Pada beberapa konfigurasi, terutama filesystem ext4, jumlah inode ditentukan ketika filesystem dibuat.

Artinya, menambahkan kapasitas disk tidak otomatis menjamin jumlah inode yang tersedia ikut bertambah.

Jika filesystem ext4 memang memiliki rasio inode yang terlalu rendah untuk pola penggunaan server, administrator dapat mempertimbangkan migrasi ke filesystem baru dengan parameter pembuatan inode yang lebih sesuai.

Salah satu parameter yang berkaitan adalah -i pada mkfs.ext4.

Sebagai contoh konseptual:

mkfs.ext4 -i 4096 /dev/DEVICE

Jangan menjalankan perintah tersebut pada filesystem produksi yang sedang digunakan.

Pembuatan filesystem baru dapat menghancurkan seluruh data pada target device. Sebelum melakukan migrasi, kamu harus:

1. Memastikan device target benar.
2. Menyiapkan backup lengkap.
3. Memverifikasi integritas backup.
4. Menyiapkan filesystem baru pada storage yang sesuai.
5. Memulihkan data.
6. Menguji aplikasi sebelum mengalihkan mount point.

Parameter inode harus disesuaikan dengan perkiraan jumlah file, kapasitas filesystem, dan kebutuhan aplikasi.

Pada XFS, alokasi inode memiliki mekanisme berbeda dan tidak menggunakan model jumlah inode tetap seperti ext4. Karena itu, jangan menerapkan prosedur migrasi ext4 secara langsung pada XFS.

Bagaimana Jika Inode Sudah Turun tetapi Disk Tetap Penuh?

Ada kondisi lain yang sering membingungkan administrator VPS.

Setelah menghapus banyak file, penggunaan inode mungkin sudah turun, tetapi kapasitas disk tidak menunjukkan perubahan yang diharapkan.

Salah satu penyebabnya adalah file yang sudah dihapus masih dibuka oleh proses yang sedang berjalan.

Pada Linux, menghapus file berarti menghilangkan referensi nama file dari direktori. Jika sebuah proses masih memegang file descriptor, data file tersebut belum tentu langsung dilepaskan dari filesystem.

Untuk memeriksanya, gunakan:

sudo lsof +L1

Perintah ini menampilkan file terbuka yang jumlah hard link-nya kurang dari satu, termasuk file yang sudah dihapus tetapi masih digunakan proses.

Perhatikan informasi berikut:

• COMMAND: nama proses.
• PID: ID proses.
• USER: pemilik proses.
• SIZE/OFF: ukuran file atau posisi file.
• NAME: nama file yang sedang digunakan.

Jika ditemukan file log yang sudah dihapus tetapi masih terbuka, identifikasi proses pemiliknya.

Solusi yang lebih aman adalah melakukan graceful reload atau restart terhadap layanan terkait setelah memastikan dampaknya.

Jangan langsung melakukan kill -9 terhadap proses produksi karena tindakan tersebut dapat mengganggu aplikasi dan berpotensi menyebabkan masalah lain.

Perlu dibedakan bahwa file terhapus yang masih terbuka terutama menjelaskan mengapa kapasitas block storage belum dilepaskan. Ini bukan pengganti pemeriksaan inode pada filesystem.

Cara Memastikan Inode Sudah Kembali Normal

Setelah melakukan pembersihan, jangan langsung menganggap masalah selesai.

Lakukan beberapa pemeriksaan berikut.

Periksa penggunaan inode

df -i

Pastikan nilai IFree bertambah dan IUse% turun pada filesystem yang sebelumnya bermasalah.

Periksa kapasitas disk

df -h

Pastikan kapasitas block storage juga berada pada kondisi yang sesuai.

Ingat bahwa penurunan inode tidak selalu berarti penurunan penggunaan disk dalam jumlah besar.

Periksa kembali direktori penyebab

Jalankan kembali pemeriksaan direktori yang sebelumnya menghasilkan penggunaan inode tinggi:

sudo du --inodes -x -d 2 /var/www 2>/dev/null | sort -n

Tujuannya memastikan sumber penumpukan file sudah berkurang.

Uji fungsi website

Lakukan pengujian sesuai aplikasi yang berjalan.

Untuk website, kamu dapat memeriksa respons HTTP:

curl -I https://example.com

Ganti domain dengan alamat website yang sedang diperiksa.

Periksa juga apakah:

• Upload file sudah dapat dilakukan.
• Aplikasi dapat membuat temporary file.
• Session PHP berjalan normal.
• Cron job dapat membuat file hasil proses.
• Log aplikasi tidak lagi menghasilkan error terkait penyimpanan.

Jika menggunakan PHP-FPM atau web server tertentu, periksa log layanan tersebut untuk memastikan tidak ada error baru.

Contohnya:

sudo journalctl -p err -n 50

Perintah tersebut menampilkan hingga 50 entri error terbaru dari journal systemd.

Hasilnya perlu dibaca sesuai konteks layanan dan waktu kejadian. Tidak semua error yang muncul berkaitan dengan inode.

Cara Mencegah Inode VPS Cepat Habis

Mengatasi inode penuh hanya menyelesaikan kondisi saat ini. Jika aplikasi masih menghasilkan file tanpa mekanisme retensi, masalah yang sama dapat terulang.

Ada beberapa langkah yang dapat diterapkan.

Pantau penggunaan inode secara berkala

Jangan hanya memantau kapasitas disk.

Tambahkan pemantauan inode pada sistem monitoring VPS.

Contoh pemeriksaan sederhana:

df -i

Buat alert berdasarkan persentase penggunaan inode, misalnya ketika penggunaan melewati 80% atau 90%.

Angka tersebut merupakan ambang pemantauan yang dapat disesuaikan dengan karakteristik server, bukan batas universal.

Terapkan kebijakan retensi cache

Pastikan aplikasi memiliki kebijakan untuk menghapus cache yang sudah kedaluwarsa.

Cache yang tidak memiliki batas waktu penyimpanan dapat tumbuh tanpa kendali.

Atur log rotation

Gunakan logrotate atau mekanisme logging aplikasi untuk mengendalikan jumlah file log yang tersimpan.

Sesuaikan kebijakan rotasi dengan kebutuhan audit dan troubleshooting.

Evaluasi sistem session PHP

Periksa konfigurasi session dan mekanisme garbage collection.

Pastikan file session lama tidak menumpuk tanpa batas, terutama pada website dengan banyak pengguna.

Periksa direktori temporary

Pantau /tmp dan /var/tmp.

Pastikan aplikasi tidak meninggalkan file sementara secara permanen.

Gunakan kebijakan pembersihan yang mempertimbangkan umur file dan kebutuhan aplikasi.

Sesuaikan filesystem dengan karakteristik aplikasi

Jika server menjalankan aplikasi yang menghasilkan jutaan file kecil, pertimbangkan kebutuhan inode sejak awal provisioning VPS.

Khusus untuk ext4, perencanaan jumlah inode perlu diperhatikan ketika filesystem dibuat.

Jika pola aplikasi berubah secara signifikan, evaluasi kembali apakah filesystem yang digunakan masih sesuai.

FAQs

1. Apa penyebab VPS kehabisan inode padahal disk masih kosong?

Penyebab utamanya adalah jumlah file dan direktori sudah mencapai batas inode pada filesystem. Hal ini sering terjadi akibat penumpukan cache, session PHP, file temporary, log aplikasi, atau file kecil dari banyak website.

2. Bagaimana cara mengetahui inode VPS sudah penuh?

Jalankan:

df -i

Periksa kolom IUse%. Jika nilainya 100%, filesystem tersebut sudah tidak memiliki inode bebas.

Pastikan juga memeriksa mount point yang benar karena setiap filesystem dapat memiliki kapasitas inode berbeda.

3. Apakah menambah kapasitas SSD atau disk VPS bisa mengatasi inode penuh?

Belum tentu.

Menambahkan kapasitas disk tidak otomatis menambah jumlah inode yang tersedia, terutama pada filesystem ext4 yang jumlah inode-nya ditentukan saat pembuatan filesystem.

Solusinya bergantung pada jenis filesystem dan konfigurasi penyimpanan yang digunakan.

4. Apakah menghapus file besar bisa mengurangi penggunaan inode?

Bisa, karena setiap file umumnya menggunakan inode terlepas dari ukuran datanya.

Namun, menghapus satu file berukuran 10 GB hanya membebaskan sekitar satu inode untuk file tersebut. Sebaliknya, menghapus ribuan file kecil dapat membebaskan ribuan inode.

Karena itu, ketika menghadapi inode exhaustion, jumlah file sering lebih penting untuk diperhatikan daripada ukuran file.

5. Apakah inode penuh bisa menyebabkan website down?

Bisa.

Jika filesystem yang digunakan website kehabisan inode, aplikasi dapat gagal membuat file baru, menyimpan session, menulis cache, atau menghasilkan temporary file.

Dampaknya bergantung pada filesystem dan komponen aplikasi yang terdampak. Website tidak selalu langsung down, tetapi fungsi tertentu dapat mengalami kegagalan.

Penutup

VPS kehabisan inode meskipun disk masih kosong merupakan masalah yang berbeda dari kapasitas penyimpanan yang benar-benar penuh.

Pemeriksaan pertama yang sebaiknya kamu lakukan adalah membandingkan hasil df -h dengan df -i. Jika penggunaan inode sudah mencapai 100%, lanjutkan dengan mengidentifikasi direktori yang menghasilkan file paling banyak menggunakan du --inodes dan find.

Setelah sumber masalah ditemukan, lakukan pembersihan berdasarkan fungsi file tersebut. Cache, session, temporary file, dan log dapat menjadi kandidat pembersihan, tetapi masing-masing membutuhkan penanganan yang sesuai.

Jika masalah terus berulang meskipun file tidak lagi menumpuk, evaluasi konfigurasi aplikasi, quota pengguna, dan karakteristik filesystem yang digunakan.

Dengan memantau inode secara terpisah dari kapasitas disk, kamu dapat mendeteksi potensi masalah lebih awal sebelum aktivitas website dan layanan VPS terganggu.