Inodedega (index node) tähistatakse serveri failisüsteemis kasutatavaid andmete objekte – kõik failid, kataloogid, E-kirjad jne. Inodede arv kliendikontol mõjutab kliendi kodulehe, blogi, foorumi või e-poe ning serveri töö kvaliteeti.
cPaneli halduskeskkonnas oleneb paketis lubatud inodede vastavalt paketi kasutusressurssidest.
Peamised probleemid, mis võivad liiga suure inodede mahu juures:
+ Varukoopiate tegemine ja varukoopiatest taastamine on selliste kataloogide puhul ajaliselt väga mahukas ning mõjutab jagatud serveril kõigi klientide teenuse kvaliteeti
+ Meili/FTP/veebilehe kasutamine ei õnnestu, kui on vaja uusi faile kirjutada/salvestada (sh. logifailid).
+ Kui kataloogis väga palju objekte (sadu tuhandeid), siis võib sellise kataloogi haldamine muutuda kliendipoolselt sisuliselt võimatuks – ei ole võimalik faile iseseisvalt isegi kustutada. Seda saab teha ainult teenusepakkuja serveri administraator.
Kuidas selline olukord tekib?
Kõige levinum põhjus on hooletult loodud või vigane tarkvara. Kui kodulehe tarkvara loob ajutisi faile, mida rakenduse käivitamise järel ei kustutata, siis nende arv kasvab lõpmatult, tuues kaasa suurema koormuse serverile, mõnikord ka kodulehe või tema osade töö aeglustumise või töö lakkamise.
Sageli kasutakse tarkvara, mis on saadav vabavarana ning mõeldud näiteks väikeste e-poodide loomiseks. Kui aga pood kasvab suureks, siis võib tekkida probleeme. Näiteks kui e-poe tarkvara loob igast toote pildist erineva suurusega versioonid, siis väikese toodete arvu juures see probleeme ei tekita, aga mahu kasvades on tulemuseks sajad tuhanded või miljonid eri failid.
Milline on lahendus?
Piirang inodede kasutuse osas on kehtestatud selleks, et kaitsta kõiki meie kliente, kes kasutavad jagatud serveri ressurssi. Probleem puudutab väga väikest arvu kliente, kuid igaüks saab omalt poolt aidata kaasa sellele, et serveri ja konto töö toimiks tõrgeteta. Selleks tuleb lihtsalt hoolitseda selle eest, kontol ei hoitaks aegunud ja tarbetuid andmeid ja faile, puhtana tuleks hoida ka meilikontod. Kui teie kontol on meilikontosid, mida enam ei kasutata, palume need eemaldada.
+ Eemalda serverilt vanad ja tarbetud failid, kataloogid ja andmebaasid
+ Kui sul on paigaldatud rakendusi või kodulehe tarkvara, mida enam ei kasutata, tuleks ka need eemaldada
+ Meilikontode sisu tuleks kriitilise pilguga ĂĽle vaadata, puhastada postkast tarbetutest kirjadest
+ Kui kontol on loodud varukoopiaid, mis on juba mitu aastat vanad, tuleks kaaluda, kas nende säilitamine on mõttekas – näiteks aastal 2012 loodud varukoopia Joomlast ei pruugi enam uuema PHP versiooniga keskkonnas töölegi hakata, lisaks võib vanem tarkvara sisaldada turvaauke.
Näidisjuhendeid
1. Magento e-poe korral sessioonifailid
Probleem võib olla olenevalt kasutusel olevast tarkvara versioonist, kas liiga pika “elueaga” olevad sessioonifailid või otsirobotite korral massiline sessioonifailide genereerimine. Kuna Magento kasutab eraldi kausta sessioonifailide salvestamiseks, siis server neid ise sealt selliselt ei eemalda!
Mida tuleks teha:
– Tuleks Magento adminkeskkonnast kontrollida üle sessiooni kestvus/pikkus ja määrata see ajavahemikku maksimaalselt kuni 2h (reeglina ei ole kliendid e-poe lehel nö. idle olekus kauem ning Magento oskab olemasolevat sessiooni vajadusel taasluua. Lisaks oleks kuni 2h mõistlik maksimaalne aeg vana sessiooni “turvalise kasutamise” tagamiseks)
– Kui probleemne koht siiski jätkub või genereerivad massiliselt otsirobotid sessioone:
a) Teil on Magento versioon 1.* – saab abi juhendist: https://magento.stackexchange.com/a/120587
b) Teil on Magento versiooniga 2.* või uuem – Saab abi moodulist: flancer32/mage2_ext_bot_sess @GitHub
2. E-poe korral sessioonifailid, kui e-pood ei oska ise nende haldamisega toime tulla
NB! Alati tuleks kõigepealt uurida, miks e-pood ei oska ise sessioone hallata või kas/miks ta genereerib neid hulgaliselt otsirobotitele!
(Mida aeg edasi, seda rohkem oleme täheldanud e-poodidel (eriti vanematel versioonidel) sessioonimuresi, tulenevalt otsi-/paharobotite/bottide/spiderite suurenenud aktiivsusele)
Kui eelnevalt kirjeldatule siiski lahendust ei leia, ehk e-poe tarkvaraarendajad ei ole vastavat koodipaika Teie e-poele väljastanud, saab sessioonide eemaldamise ka automatiseerida croni kaudu kaustast, kuhu Teie e-pood sessioone salvestab (erinev igal rakendusel!) – näidiskood oleks:
/usr/bin/find /home/npXXXXXXXX/public_html/var/sessions/ -type f -name sess\* -mtime +6 -execdir rm -f {} \;
(Kus siis kasutajatunnus ja tee konkreetse kaustani tuleks ära muuta Teie e-pole sessioonikaustale vastavalt!)
3. CRON loob liiga palju logifaile
Näidisena saaks kasutada välja toodud näidet, kuidas salvestada fail per päev:
PHP:
/usr/local/bin/php /home/npXXXXXXXX/public_html/cron.php >> /home/npXXXXXXXX/public_html/cronlog/`date "+\%Y\%m\%d"`-cron.log 2>$
WGET:
/bin/wget http://domeen.tld/cron.php -qO - >>/home/npXXXXXXXX/public_html/cronlog/`date "+\%Y\%m\%d"`-cron.log
(Siinkohal siis mitte ei looda igal CRON käivitusel uut faili vaid output saadetakse per päev olevasse logifaili – kindlasti tuleks neid ajajooksul samuti hooldada/eemaldada vanad mittevajalikud logifailid)
Vanemate logifailide kui 1 nädal (7 päeva) kustutamine (eelpool näitena kasutatud kataloogist):
/usr/bin/find /home/npXXXXXXXX/public_html/cronlog/ -type f -name \*.log -mtime +6 -execdir rm -f {} \;
KĂĽsimused/Vastused
K: “Olen teie veebimajutuse klient, kas ma saan oma kontol ka ise kuidagi inodede arvu tuvastada/kontrollida?”
V: Jah, inodede arvu näete täpselt, logides sisse SSH kaudu ja käivitades käsureal koodi:
echo "Detailed Inode usage for: $(pwd)" ; for d in `find -maxdepth 1 -type d |cut -d\/ -f2 |grep -xv . |sort`; do c=$(find $d |wc -l) ; printf "$c\t\t- $d\n" ; done ; printf "Total: \t\t$(find $(pwd) | wc -l)\n"
Kui soovite kuvada top 10 kausta, kus on rohkem faile, saate käivitada käsu:
du --inodes . | sort -rn | head -10
(SSH õpetus on leitav siin: SSH ühenduse kasutamine)