Paano ko susuriin ang paggamit ng inode sa HestiaCP? Ano ang sanhi ng kawalan ng kakayahang magsulat ng mga file kahit na may sapat na espasyo sa disk?

Ilang araw na ang nakalipas, nag-message sa akin ang isang kaibigan ko kagabi at sinabing nag-crash ang server niya.

Ang mga partikular na sintomas ay partikular na kakaiba: biglang nagsimulang magpakita ng mga error ang website, hindi maisulat ang mga log, at ang paglikha ng mga bagong file ay agad na magpapakita na puno na ang disk.

Pero nang tignan niya gamit ang `df -h`, laking gulat niya nang malaman na ang disk ay malinaw na may sampung gigabytes na libreng espasyo. Paano ito napuno?

Sinabi ko sa kanya noon din, "Kuya, hindi lang puro espasyo ang laman mo, overloaded na rin ang Inode mo."

Sumagot siya nang may bahid ng pagtatanong: Ano nga ba ang Inode?

Sa katunayan, maraming tao ang eksaktong katulad ng reaksyon niya noong una silang nahulog sa patibong na ito, dahil walang sinuman sa paaralan ang nagturo sa kanila ng mga bagay na ito.

Linawin muna natin kung ano ang isang Inode.

Isipin ito bilang isang library index card, at madali itong mauunawaan.

Ang espasyo sa disk ay parang isang bookshelf; kung gaano karaming libro ang maaari mong ilagay dito ay depende sa kapasidad nito, na madaling maunawaan ng lahat.

Ang inode ay parang index card para sa bawat libro, na nagtatala ng pangalan, lokasyon, at kung sino ang naglipat nito.

Sa Linux , ang bawat file at bawat direktoryo ay dapat sumakop sa isang inode, gaano man kaliit ang file.

Kahit na ito ay isang walang laman na file, gagamit pa rin ang system ng index card para dito.

Ang sistema ay may limitasyon sa kabuuang bilang ng mga file na maaari nitong gawin; ang limitasyong ito ay ang kabuuang bilang ng mga innode.

Kapag naubos na ang inode, kahit na mayroon pa ring daan-daang gigabytes na libreng espasyo ang iyong disk, tatanggi ang operating system na lumikha ng anumang mga bagong file.

Hindi maisulat ang mga log, hindi makakagawa ng cache, at tuluyang nagka-crash ang website—iyan ang kakaibang eksenang nasasaksihan mo.

Sa totoo lang, ito ay isang napakahirap na sitwasyon dahil ang mensahe ng error ay ipinapadala mula sa isang lokasyon na hindi mo tinitingnan.

Ang unang paraan ay ang paggamit ng `df -i` para makakuha ng kumpletong pangkalahatang-ideya.

Sa HestiaCP environment, maaari mo lang i-SSH ang terminal at i-type ang linyang ito.

df -i

Ililista nito ang kabuuang bilang ng mga innode, ang bilang na ginamit, at ang bilang na natitira para sa bawat naka-mount na partisyon.

Sa output, mayroong isang column na tinatawag na IUse%, na siyang pangunahing sukatan na dapat mong bantayan.

Kung ang IUse% ng isang partisyon ay umabot sa 100%, kahit na ang partisyon na iyon ay mayroon pa ring sapat na espasyo sa disk, hindi na ito makakagawa ng anumang mga bagong file o log.

Iminungkahi ko sa kaibigan ko na patakbuhin muna niya ito, para matukoy nito kung ang problema ay nasa Inode sa loob ng isang segundo , na mas mabilis kaysa sa panghuhula.

Ang pangalawang paraan ay ang paggamit ng `find` upang tumpak na mabilang ang isang partikular na user.

Matapos makumpirma na ang problema ay nasa innode, ang susunod na hakbang ay alamin kung sino ang labis na gumagamit ng index card.

Ang HestiaCP ay may hiwalay na home directory para sa bawat user. Maaari mo lang bilangin ang kabuuang bilang ng mga file at directory sa ilalim ng isang partikular na directory ng website.

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

Palitan ang "username" at "iyong domain name" ng iyong aktwal na path. Ang purong numerong ibinalik ng terminal ay ang kabuuan ng lahat ng mga file at folder sa direktoryong iyon.

Ang bawat file o direktoryo ay tumutugma sa isang inode, kaya ang numerong ito ay kumakatawan sa paggamit ng inode.

Kung tinatamad kang suriin ang bawat isa nang paisa-isa at gusto mong makita ang distribusyon ng paggamit ng lahat ng user sa buong site nang sabay-sabay, mayroon ding single loop command.

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

Ipi-print ng linyang ito ang kabuuang bilang ng mga file sa bawat direktoryo ng user sa ilalim ng /home, na ginagawang madaling matukoy kung aling direktoryo ng user ang may abnormal na mataas na bilang ng mga file.

Ang ikatlong estratehiya ay ang pagtukoy sa mga subdirektoryo na kumukonsumo ng pinakamaraming iodine.

Minsan alam mong napakataas ng mga value ng Inode ng isang website, pero hindi mo pa rin malaman kung ano ang problema kung puno ng mga file ang screen nito.

Sa ganitong mga kaso, kailangan mong mag-drill down sa isang antas upang mahanap ang mga subfolder na naglalaman ng isang malaking bilang ng maliliit na file, tulad ng mga direktoryo ng cache, direktoryo ng session, at direktoryo ng log—ito ang mga pinakaproblemadong lugar.

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

Ililista ng utos na ito ang nangungunang 10 subfolder na kumukonsumo ng pinakamaraming file.

Ang landas sa pinakatuktok ng listahan ay kung saan ang isang malaking bilang ng maliliit na file ay magkakasamang nakakumpol.

Sinabi ko sa kaibigan ko na malamang isa itong caching plugin na palihim na bumubuo ng maliliit na file, at ang pagpapatakbo ng linyang ito ay halos makapagpapatunay nito.

Ang pang-apat na tip ay ang pagsuri sa limitasyon ng quota gamit ang repquota.

Kung naka-enable ang mga quota ng Linux file system sa iyong server, maaari mong tingnan ang problema mula sa ibang perspektibo.

repquota -a

Itataas ng utos na ito ang limitasyon ng file at aktwal na paggamit ng file para sa lahat ng user.

Bigyang-pansing mabuti ang seksyong Mga Limitasyon ng File sa output; ang kolum na ginamit ay nagpapahiwatig kung gaano karaming mga file ang nagamit na.

Ang mga kolum na "malambot" at "matigas" ay kumakatawan sa mga limitasyon ng malambot at matigas na limitasyon. Kapag ang "gamitin" ay umabot na sa "matigas", direktang tatanggi ang sistema na gumawa ng mga bagong file.

Ito ay isang ganap na kakaibang kwento mula sa kung gaano karaming espasyo ang natitira sa iyong disk.

Para matapos ang lahat, pagdugtungin natin ang mga detalye ng imbestigasyon.

Balikan natin yung kaibigan na nag-crash ng server sa kalagitnaan ng gabi noong umpisa.

Sinundan niya ang apat na hakbang na inilarawan ko, simula sa `df -i` para kumpirmahin na puno na nga ang inode.

Pagkatapos, gamit ang find, nahanap namin ang cache directory ng isang inabandunang lumang website na mabilis na bumubuo ng maliliit na file.

Sa wakas, nakumpirma ng pagsusuri sa 'repquota' na naabot na nga nito ang itinakdang limitasyon.

Matapos linisin ang tambak na junk cache, agad na nabuhay muli ang website.

Kaya sa susunod na makaranas ka ng kakaibang sitwasyong ito kung saan "malinaw na may espasyo ang disk ngunit hindi ka maaaring magsulat ng mga file," huwag magmadaling magdagdag ng hard drive.

Una, gamitin ang `df -i` para tingnan ang inode; ang katotohanan ay maaaring nakatago sa index card na hindi mo pa napansin noon.

Tunay akong naniniwala na ang maliliit na sentido komun na ito na nakatago sa kaibuturan ng sistema ay mas kapaki-pakinabang kaysa sa pagmemorya ng isang daang listahan ng pag-optimize.