HestiaCP'de inode kullanımını nasıl kontrol ederim? Yeterli disk alanı olmasına rağmen dosya yazamamanın sebebi nedir?

Birkaç gün önce, bir arkadaşım gece geç saatlerde bana mesaj atarak sunucusunun çöktüğünü söyledi.

Belirtilen belirtiler özellikle tuhaftı: web sitesi aniden hatalar vermeye başladı, günlük dosyaları yazılamıyordu ve yeni dosyalar oluşturulurken hemen diskin dolu olduğu uyarısı veriliyordu.

Ancak `df -h` komutuyla kontrol ettiğinde, diskin onlarca gigabayt boş alana sahip olduğunu görünce şok oldu. Nasıl dolu olabilirdi ki?

Ona o anda, "Kardeşim, sadece depolama alanın dolu değil, Inode'un da aşırı yüklü," dedim.

Soru işaretiyle karşılık verdi: İnod tam olarak nedir?

Aslında birçok insan, bu tuzağa ilk düştüklerinde tıpkı onun gibi tepki veriyor, çünkü okulda kimse onlara bu konuları öğretmemişti.

Öncelikle Inode'un ne olduğunu açıklığa kavuşturalım.

Bunu bir kütüphane bilgi kartı gibi düşünün, o zaman anlaması kolay olacaktır.

Disk alanı tıpkı bir kitaplık gibidir; üzerine kaç kitap koyabileceğiniz, kapasitesine bağlıdır; bunu herkes kolayca anlayabilir.

Bir inode, her kitap için bir tür indeks kartı gibidir; kitabın adını, yerini ve kimin taşıdığını kaydeder.

Linux'ta , dosya ne kadar küçük olursa olsun, her dosya ve her dizin bir inode (nokta içi bellek) işgal etmelidir.

Dosya boş olsa bile, sistem yine de onun için bir indeks kartı kullanacaktır.

Sistem, oluşturabileceği toplam dosya sayısında bir sınıra sahiptir; bu sınır, toplam innode sayısıdır.

İnode dolduktan sonra, diskinizde yüzlerce gigabayt boş alan olsa bile, işletim sistemi yeni dosya oluşturmayı reddedecektir.

Kayıtlar yazılamıyor, önbellek oluşturulamıyor ve web sitesi tamamen çöküyor; şu anda şahit olduğunuz tuhaf manzara bu.

Dürüst olmak gerekirse, bu gerçekten karmaşık bir durum çünkü hata mesajı sizin bakmadığınız bir yerden gönderiliyor.

İlk yöntem, hızlı bir genel bakış elde etmek için `df -i` komutunu kullanmaktır.

HestiaCP ortamında , terminale SSH ile bağlanıp şu satırı yazmanız yeterlidir.

df -i

Bu komut, her bir bağlı bölüm için toplam innode sayısını, kullanılan innode sayısını ve kalan innode sayısını listeleyecektir.

Çıktıda, dikkat etmeniz gereken en önemli ölçüt olan IUse% adlı bir sütun bulunmaktadır.

Bir bölümün IUse% değeri %100'e ulaşırsa, o bölümde hala yeterli disk alanı olsa bile, artık yeni dosya veya günlük dosyası oluşturamaz.

Arkadaşıma önce bunu çalıştırmasını önerdim, böylece sorunun Inode'dan kaynaklanıp kaynaklanmadığını saniyeler içinde tespit edebilirdi ; bu , tahminde bulunmaktan çok daha hızlı olurdu.

İkinci yöntem ise belirli bir kullanıcıyı tam olarak saymak için `find` komutunu kullanmaktır.

Sorunun innode ile ilgili olduğunu doğruladıktan sonraki adım, indeks kartını aşırı miktarda kullanan kişiyi bulmaktır.

HestiaCP'nin her kullanıcı için ayrı bir ana dizini vardır. Belirli bir web sitesi dizini altındaki toplam dosya ve dizin sayısını kolayca sayabilirsiniz.

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

"Kullanıcı adı" ve "alan adınız" ifadelerini gerçek yolunuzla değiştirin. Terminal tarafından döndürülen saf sayı, o dizindeki tüm dosya ve klasörlerin toplamıdır.

Her dosya veya dizin bir inode'a karşılık gelir, dolayısıyla bu sayı inode kullanımını temsil eder.

Her birini tek tek kontrol etmekle uğraşmak istemiyorsanız ve tüm site genelindeki kullanıcıların kullanım dağılımını bir kerede görmek istiyorsanız, tek bir döngü komutu da mevcuttur.

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

Bu satır, /home altındaki her kullanıcı dizinindeki toplam dosya sayısını yazdırarak, hangi kullanıcı dizininde anormal derecede yüksek sayıda dosya olduğunu tespit etmeyi kolaylaştırır.

Üçüncü strateji, en fazla iyot tüketen alt dizinleri belirlemektir.

Bazen bir web sitesinin Inode değerlerinin inanılmaz derecede yüksek olduğunu bilirsiniz, ancak ekrandaki dosyalarda neyin yanlış olduğunu yine de anlayamazsınız.

Bu gibi durumlarda, çok sayıda küçük dosya içeren alt klasörleri bulmak için bir alt seviyeye inmeniz gerekir; bunlar en sorunlu alanlardır.

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

Bu komut, en çok dosya tüketen ilk 10 alt klasörü listeleyecektir.

Listenin en üstündeki yol, çok sayıda küçük dosyanın bir araya toplandığı yerdir.

Arkadaşıma bunun muhtemelen gizlice küçük dosyalar oluşturan bir önbellekleme eklentisi olduğunu ve bu satırı çalıştırmanın bunu doğrulayacağını söyledim.

Dördüncü ipucu, repquota kullanarak kota limitini kontrol etmektir.

Eğer sunucunuzda Linux dosya sistemi kotaları etkinleştirilmişse, soruna farklı bir açıdan bakabilirsiniz.

repquota -a

Bu komut, tüm kullanıcılar için dosya limitini ve gerçek dosya kullanımını gösterecektir.

Çıktıdaki Dosya Sınırları bölümüne dikkatlice bakın; kullanılan sütunu kaç dosyanın kullanıldığını gösterir.

"Yumuşak" ve "sert" sütunları, yumuşak ve sert limit eşiklerini temsil eder. "Kullanılan" değeri "sert" değerine ulaştığında, sistem yeni dosya oluşturmayı doğrudan reddedecektir.

Bu, diskinizde ne kadar boş alan kaldığıyla tamamen farklı bir konu.

Özetlemek gerekirse, soruşturmanın noktalarını birleştirelim.

Şimdi, en başta gece yarısı sunucuyu çökerten arkadaşımıza geri dönelim.

Anlattığım dört adımı izledi; ilk olarak inode'un gerçekten dolu olduğunu doğrulamak için `df -i` komutunu kullandı.

Ardından, `find` komutunu kullanarak, çılgın gibi küçük dosyalar üreten terk edilmiş eski bir web sitesinin önbellek dizinini bulduk.

Son olarak, `repquota`'yı kontrol etmek, gerçekten de üst sınıra ulaşıldığını doğruladı.

Önbellekteki gereksiz verileri temizledikten sonra, web sitesi anında tekrar çalışmaya başladı.

Dolayısıyla, bir dahaki sefere "diskte açıkça yer var ama dosya yazamıyorsunuz" gibi garip bir durumla karşılaşırsanız, hemen bir sabit disk eklemeye acele etmeyin.

Öncelikle, inode'a göz atmak için `df -i` komutunu kullanın; gerçek, daha önce hiç fark etmediğiniz o indeks kartında saklı olabilir.

Sistemin özünde gizli olan bu küçük sağduyu parçalarının, yüzlerce optimizasyon listesini ezberlemekten çok daha faydalı olduğuna gerçekten inanıyorum.