Bagaimanakah saya boleh menyemak penggunaan inode dalam HestiaCP? Apakah yang menyebabkan ketidakupayaan untuk menulis fail walaupun terdapat banyak ruang cakera?

Beberapa hari yang lalu, seorang rakan menghantar mesej kepada saya lewat malam mengatakan bahawa pelayannya telah ranap.

Simptom-simptom khusus itu amat pelik: laman web tiba-tiba mula memaparkan ralat, log tidak dapat ditulis, dan penciptaan fail baharu akan segera menunjukkan bahawa cakera telah penuh.

Tetapi apabila dia menyemak dengan `df -h`, dia terkejut apabila mendapati cakera itu jelas mempunyai puluhan gigabait ruang kosong. Bagaimana ia boleh penuh?

Saya beritahu dia ketika itu juga, "Abang, bukan sahaja ruang simpanan awak penuh, Inode awak pun terlebih muatan."

Dia menjawab dengan tanda tanya: Apakah sebenarnya Inode?

Malah, ramai orang bertindak balas dengan cara yang sama seperti yang dilakukannya apabila mereka mula-mula terjebak dalam perangkap ini, kerana tiada sesiapa di sekolah yang pernah mengajar mereka perkara ini.

Mari kita jelaskan apa itu Inode terlebih dahulu.

Anggaplah ia sebagai kad indeks perpustakaan, dan ia akan mudah difahami.

Ruang cakera umpama rak buku; berapa banyak buku yang boleh anda letakkan di atasnya bergantung pada kapasitinya, yang mudah difahami oleh semua orang.

Inod adalah seperti kad indeks untuk setiap buku, yang merekodkan namanya, lokasi dan siapa yang memindahkannya.

Dalam Linux , setiap fail dan setiap direktori mesti menempati inode, tidak kira betapa kecilnya fail tersebut.

Walaupun ia fail kosong, sistem masih akan menggunakan kad indeks untuknya.

Sistem ini mempunyai had kepada jumlah fail yang boleh dicipta; had ini ialah jumlah innod.

Sebaik sahaja inode habis digunakan, walaupun cakera anda masih mempunyai ratusan gigabait ruang kosong, sistem pengendalian akan enggan mencipta sebarang fail baharu.

Log tidak boleh ditulis, cache tidak boleh dicipta dan laman web ranap sepenuhnya—itulah pemandangan pelik yang anda sedang saksikan.

Sejujurnya, ini adalah situasi yang sangat rumit kerana mesej ralat dihantar dari lokasi yang tidak anda lihat.

Cara pertama ialah menggunakan `df -i` untuk mendapatkan gambaran keseluruhan yang lengkap.

Dalam persekitaran HestiaCP , anda boleh memasukkan SSH ke dalam terminal dan menaip baris ini.

df -i

Ia akan menyenaraikan jumlah bilangan innod, bilangan yang digunakan dan bilangan yang tinggal untuk setiap partition yang dipasang.

Dalam output, terdapat lajur yang dipanggil IUse%, yang merupakan metrik utama yang perlu anda perhatikan.

Jika IUse% sesuatu partition mencapai 100%, walaupun partition tersebut masih mempunyai banyak ruang cakera, ia tidak lagi dapat mencipta sebarang fail atau log baharu.

Saya mencadangkan kepada rakan saya agar dia menjalankan ini terlebih dahulu, supaya ia dapat menentukan sama ada masalahnya adalah dengan Inode dalam sekelip mata , yang akan menjadi jauh lebih pantas daripada meneka.

Kaedah kedua adalah dengan menggunakan `cari` untuk mengira pengguna tertentu dengan tepat.

Selepas mengesahkan bahawa masalahnya adalah pada innode, langkah seterusnya adalah untuk mengetahui siapa yang menggunakan kad indeks secara berlebihan.

HestiaCP mempunyai direktori utama yang berasingan untuk setiap pengguna. Anda boleh mengira jumlah fail dan direktori di bawah direktori laman web tertentu.

find /home/用户名/web/你的域名/public_html | wc -l

Gantikan "nama pengguna" dan "nama domain anda" dengan laluan sebenar anda. Nombor tulen yang dikembalikan oleh terminal ialah jumlah semua fail dan folder dalam direktori tersebut.

Setiap fail atau direktori sepadan dengan satu inode, jadi nombor ini mewakili penggunaan inode.

Jika anda terlalu malas untuk menyemak setiap satu secara individu dan ingin melihat taburan penggunaan semua pengguna di seluruh laman web sekaligus, terdapat juga arahan gelung.

for d in /home/*; do echo -n "$d: "; find "$d" 2>/dev/null | wc -l; done

Baris ini akan mencetak jumlah fail dalam setiap direktori pengguna di bawah /home, menjadikannya mudah untuk mengenal pasti direktori pengguna yang mempunyai bilangan fail yang luar biasa tinggi.

Strategi ketiga adalah untuk mengenal pasti subdirektori yang paling banyak menggunakan iodin.

Kadangkala anda tahu sesebuah laman web mempunyai nilai Inode yang sangat tinggi, tetapi anda masih tidak dapat mengetahui apa yang salah dengan skrin yang penuh dengan fail.

Dalam kes sedemikian, anda perlu menelusuri satu tahap untuk mencari subfolder yang mengandungi sejumlah besar fail kecil, seperti direktori cache, direktori sesi dan direktori log—ini adalah kawasan yang paling bermasalah.

find /home/用户名/web/你的域名/public_html -type d -exec sh -c 'echo -n "{}: "; find "{}" -maxdepth 1 | wc -l' \; | sort -n -r -k 2 | head -n 10

Arahan ini akan menyenaraikan 10 subfolder teratas yang menggunakan paling banyak fail.

Laluan di bahagian paling atas senarai ialah tempat sebilangan besar fail kecil dikumpulkan bersama.

Saya memberitahu rakan saya bahawa ia mungkin sejenis plugin caching yang menjana fail kecil secara rahsia, dan menjalankan baris ini pada dasarnya akan mengesahkannya.

Petua keempat adalah untuk menyemak had kuota menggunakan repquota.

Jika pelayan anda telah mendayakan kuota sistem fail Linux, anda boleh melihat masalah tersebut dari perspektif yang berbeza.

repquota -a

Arahan ini akan memaparkan had fail dan penggunaan fail sebenar untuk semua pengguna.

Beri perhatian khusus kepada bahagian Had Fail dalam output; lajur yang digunakan menunjukkan bilangan fail yang telah digunakan.

Lajur "lembut" dan "keras" mewakili ambang had lembut dan keras. Sebaik sahaja "digunakan" mencapai "keras", sistem akan terus menolak untuk mencipta fail baharu.

Ini adalah cerita yang sama sekali berbeza daripada berapa banyak ruang yang tinggal pada cakera anda.

Untuk mengakhiri semuanya, mari kita hubungkan inti pati siasatan ini.

Mari kita kembali kepada rakan yang menyebabkan pelayannya rosak pada tengah malam pada mulanya.

Dia mengikuti empat langkah yang saya terangkan, bermula dengan `df -i` untuk mengesahkan bahawa inode itu sememangnya penuh.

Kemudian, menggunakan kaedah find, didapati direktori cache laman web lama yang terbengkalai sedang menjana fail kecil dengan cara yang tidak masuk akal.

Akhirnya, semakan 'repquota' mengesahkan bahawa ia sememangnya telah mencapai had yang ditetapkan.

Selepas membersihkan timbunan cache sampah itu, laman web itu kembali hidup serta-merta.

Jadi lain kali anda menghadapi situasi pelik ini di mana "cakera jelas mempunyai ruang tetapi anda tidak boleh menulis fail," jangan tergesa-gesa untuk menambah cakera keras.

Pertama, gunakan `df -i` untuk melihat inode; kebenarannya mungkin tersembunyi pada kad indeks yang tidak pernah anda perhatikan sebelum ini.

Saya benar-benar percaya bahawa sedikit akal sehat yang tersembunyi di teras sistem ini lebih berguna daripada menghafal seratus senarai pengoptimuman.