Baca peringatan memori dan disk sebelum meningkatkan.

Tangkap baseline kecil dengan konteks

Gunakan akun Linux yang diizinkan untuk memeriksa aplikasi yang Anda operasikan. Perintah di sini memeriksa status; perintah ini tidak menghapus file atau mengubah ukuran penyimpanan. Beberapa direktori dan jurnal memerlukan akses yang lebih tinggi. Ganti /var/lib/field-api, /opt/field-api dan /opt/first-api dengan path aplikasi yang sebenarnya, dan pastikan path tersebut ada sebelum menafsirkan hasilnya.

Catat waktu, rilis saat ini, dan aktivitas: lalu lintas biasa, unggahan, pekerjaan laporan, atau build deployment. Ambil pembacaan lain selama aktivitas yang sebanding. Dua tangkapan layar yang tidak terkait dapat membuat mesin yang sehat terlihat tidak konsisten. Jika pengguna sudah terdampak, tangkap petunjuk berguna pertama dari panduan kegagalan aplikasi sebelum membuat beberapa perubahan sekaligus.

Baca memori yang tersedia, lalu periksa beban kerja

free -h
ps -eo pid,comm,rss --sort=-rss | head -n 12

Di free, memori yang tersedia memperkirakan apa yang bisa digunakan untuk aplikasi baru tanpa swapping. Ini memperhitungkan cache yang dapat diklaim kembali, sehingga menjawab pertanyaan yang berbeda dari memori "bebas" yang sama sekali tidak digunakan. Lihat manual free upstream. Linux menggunakan memori untuk caching file; cache yang besar saja bukan bukti kebocoran. Referensi ikhtisar memori kernel menjelaskan mengapa cache dan memori aplikasi hidup berdampingan.

Pembacaan ilustratif, bukan pengukuran server: host kecil memiliki sekitar 1.9 GiB memori yang dapat digunakan, 80 MiB bebas, dan 850 MiB tersedia. Angka bebas yang rendah saja tidak membenarkan peningkatan. Jika memori yang tersedia berulang kali mendekati nol selama laporan, permintaan melambat, dan pesan alokasi atau kehabisan memori yang relevan muncul, bukti gabungan itu patut diselidiki.

Skenario ps perintah mencantumkan RSS proses dalam KiB, terbesar lebih dulu. RSS menggambarkan memori resident, bukan akuntansi lengkap kepemilikan eksklusif; halaman bersama dapat muncul di beberapa proses. Jangan menjumlahkan setiap angka RSS dan menganggap hasilnya sebagai penggunaan host yang tepat. Referensi ps upstream mendefinisikan RSS dan pengurutan. Catat nama proses dan apakah jejaknya kembali ke level sebelumnya setelah beban kerja berakhir.

Swap yang digunakan dapat mencerminkan aktivitas sebelumnya; ini tidak membuktikan tekanan saat ini dengan sendirinya. Bedakan juga kapasitas host dari batas layanan atau kontainer. Proses yang dibatasi dapat gagal sementara host masih memiliki memori yang tersedia. Periksa batas yang dikonfigurasi dan waktu kegagalan sebelum menambah ukuran VPS. Referensi filesystem proc kernel mendokumentasikan bidang memori di balik pengamatan ini.

Temukan filesystem yang benar-benar terisi

df -h / /opt/first-api
df -i / /opt/first-api

Perintah pertama melaporkan ruang pada filesystem yang berisi path tersebut. Perintah kedua melaporkan inode, yaitu catatan filesystem yang diperlukan untuk file dan direktori. Beban kerja dengan banyak file kecil dapat menghabiskan inode sementara kapasitas byte masih tersisa. Periksa mount dan kedua jenis kapasitas daripada hanya menggunakan ukuran seluruh VPS sebagai satu-satunya angka. Lihat manual df GNU.

Path pada volume yang di-mount terpisah dapat terisi secara independen dari filesystem root. Sebaliknya, dua path yang terdaftar mungkin berada di filesystem yang sama, sehingga ruang tersedianya tidak dapat dijumlahkan. Reservasi filesystem, kuota, dan lapisan penyimpanan juga dapat memengaruhi apa yang dapat ditulis aplikasi. Satu persentase yang ditampilkan tidak mengidentifikasi pemilik pertumbuhan.

Atribusikan pertumbuhan ke log, unggahan, atau artefak

sudo du -xhd1 /var/lib/field-api
sudo du -xhd1 /var/log
sudo du -xhd1 /opt/field-api
sudo journalctl --disk-usage

GNU du memperkirakan ruang yang dialokasikan di bawah setiap direktori. Di sini -x menghindari melintasi ke filesystem lain, -h menggunakan unit yang mudah dibaca dan -d1 membatasi kedalaman yang ditampilkan. Pohon besar tetap dapat memakan waktu dan aktivitas disk untuk memindai. Kesalahan izin berarti tampilan tidak lengkap. Lihat manual du GNU. Perintah jurnal melaporkan penyimpanan jurnal, termasuk file aktif dan yang diarsipkan, seperti didokumentasikan oleh journalctl.

Bandingkan direktori terbesar dengan tujuannya:

• Log: apakah kesalahan berulang meningkatkan volume, dan apakah rotasi dikonfigurasi?
• Unggahan: apakah file pengguna yang disimpan tumbuh sesuai harapan, dan apakah unggahan parsial yang ditinggalkan diperhitungkan?
• Artefak rilis: apakah build lama menumpuk melampaui kebijakan rollback?
• File database: apakah perkakas database itu sendiri menjelaskan pertumbuhan dan kebutuhan pemeliharaan?

Jangan menghapus direktori database yang tidak dikenal atau menggunakan pembersihan volume kontainer yang luas sebagai langkah investigasi. Identifikasi kepemilikan, persyaratan retensi, dan salinan yang dapat dipulihkan terlebih dahulu. Jika df dan total direktori sangat berbeda, periksa batas mount, kesalahan akses, dan file yang masih dibuka setelah penghapusan bersama operator berpengalaman; menghapus file yang terlihat berulang kali dapat melewatkan ruang yang terpakai.

Ubah pembacaan menjadi tindakan lanjutan yang spesifik

Kasus ilustratif: memori yang tersedia tetap nyaman, tetapi direktori unggahan tumbuh sekitar 400 MiB pada masing-masing dari dua hari yang diamati. Filesystem memiliki sekitar 2 GiB tersedia. Membagi ruang yang tersisa dengan pertumbuhan jangka pendek tersebut menunjukkan hanya sekitar lima hari pada laju yang sama, sebelum memperhitungkan headroom operasional. Itu adalah perkiraan perencanaan, bukan ramalan atau tenggat aman untuk menunggu; unggahan dan pekerjaan sementara dapat datang tidak merata.

Tindakan selanjutnya adalah memeriksa retensi unggahan dan permintaan yang diharapkan, merencanakan penyimpanan tambahan jika dibenarkan, dan menetapkan peringatan cukup awal untuk bertindak. RAM lebih besar tidak akan mengatasi temuan ini. Dalam kasus lain, build deployment mungkin menciptakan puncak memori singkat sementara penyajian tetap kecil; memindahkan build dari VPS bisa lebih berguna daripada memperbesar runtime secara permanen.

Setelah perubahan yang dibenarkan, ulangi pembacaan yang sama dan satu tindakan aplikasi. Pastikan ruang benar-benar tersedia dan data yang dimaksud masih berfungsi. Jaga penghapusan dan pengubahan ukuran sebagai operasi terencana dengan langkah pemulihan, bukan respons otomatis terhadap angka merah. Gunakan panduan anggaran sumber daya untuk mengubah kebutuhan yang terbukti menjadi pilihan konfigurasi, dan latih pemulihan sebelum bergantung pada pembersihan atau migrasi.