Ma szépen lehalt az egyik VPS-m.
A rendszeren semmi sem működik még a pid fájlokat sem tudja létrehozni,
mondván hogy nem tud írni a HDD-re, mert az tele van.
Ennek ellenére df szerint 41% szabad hely van.
De még egy mc-t sem tudok indítani, mert az sem tud temp fájlt létrehozni.
Itt jön a csavar.
Törlök 3GB apt cache-t, utána 2 percig jó, aztán megint minden elromlik.
Gondoltam, hogy szolgáltató oldalon van a gond.
Több tárhelyet osztottak ki, mint ami van, és elfogyott.
Hogy ezt kiderítsem visszatöltöttem egy korábbi snapshotot, ott minden megy.
Ezek alapján valami OS szinten eshetett szét, és nem szolgáltató oldalon.
A vps egy websezrver, és nagyon kellemetlen állva látni, a snapshot meg túl régi...
Van ötletetek hol kellene keresni a hibát?
Köszönöm előre is :)
Debian 6.0
Apache Mysql Sendmail Webmin, más nagyon nincs rajta...
Esxi
Hozzászólások
Nezz egy df -i kimenetet, lehet, hogy az inodejaid fogytak el.
--
|8]
IFree = 0
Jól sejtem, hogy az inodes a tárolható fájlok maximális számát jelenti?
Ha igen, akkor ezt hogyan lehet növelni?
formázáskor be lehet állítani, hogy utána hogyan, azt nem tudom
utólag sehogy.
backup - mkfs - restore...
illetőleg, ha megnöveled a fájlrendszer méretét, akkor értelemszerűen arányosan több inode is lesz.
Nagyjabol jol sejted, es novelni ujraformazassal lehet csak. (ext* eseteben legalabbis, mashol nem tudom van-e lehetoseg formazas nelkul, de valoszinuleg nincs)
--
|8]
Ha átmeneti megoldás kell, akkor keresd meg azt / azokat a könyvtárakat, ahol végtelen mennyiségű (kicsi) file van és pillanatnyilag nincs rá szükség, majd targz. Ez szabadít fel annyi inode-ot, amivel tudsz addig dolgozni amíg végleges megoldást nem találsz.
Esetleg csinálhatsz egy nagy file-t, benne ext3, majd azt felmountolva odamozgatod azt a könyvtárat amiben a sok file-od van. Meglehetősen lassú lesz, de ezzel is kapsz egy kis időt kitalálni hovatovább (pl.: új diszk bele, amit már több inode-dal formázol, stb.)
--
"A herceg én vagyok."
Maga a kiváltó ok végtelenül egyszerű volt.
Adott egy hatalmas weboldal codeigniter keretrendszer felett.
A keretrendszer azt csinálja, hogy minden egyes req. url-t cache-el egy-egy fájlba.
Jelen esetben ez ~egymillió fájlt jelentett, és elfogytak az inode-ok.
Hirtelen megoldásnak egy cache ürítés megoldotta.
Azért az sem volt triviális. "rm *" pl. behal too long argument list exceptionnal ennyi fájlnál :)
Hosszabb távon a külön partíció sok-sok inode-al bemountolva a cache mappa alá...
Vagy eleve olyan fs használata, ahol nincsenek inode-ok, pl. reiserfs. Vagy dinamikus az inode tábla (jfs, xfs??).
Szerintem hatekonyabb olyan keretrendszert hasznalni ami nincs elbaszva fundamentalisan ;]
Akkor nem kell OS szinten workaroundolni a hulyesegeit.
--
|8]
Általában ez - az amúgy jobb - megoldás nem opció. Viszont azzal nincs baj, hogy sok fájlt csinál, max. amiatt lehet neheztelni a fejlesztőre, hogy miért egy könyvtárba potyogtatja azokat, miért nem egy struktúrába. Az se kizárt, hogy ez nem normális állapot(*).
A levelezésünk most épp félmillió fájlból áll - mailstore -, de egyfelől készültem erre, ezért 2% a foglalt inode, másfelől meg nem is egy könyvtárban vannak, így valamelyest jobban kezelhető.
*) Fél másodperc google után ezt találtam: http://ellislab.com/codeigniter/user-guide/general/caching.html
$this->output->cache(n);
Where n is the number of minutes you wish the page to remain cached between refreshes.
Lehet hogy nem a keretrendszer a hülye :D
Ha struktúrába rakja a ~millió file-t, ugyanúgy el fog fogyni a hely (minden file, könyvtár eszi az inode-ot, függetlenül a struktúrától).
--
"A herceg én vagyok."
Persze, de könnyebb kezelni. Nomeg nem kizárt hogy sebességszempontból se hülyeség.
A fél másodperc Google általában fél információt eredményez...
Attól hogy egy cache file lejárt nem fog törlődni,
mindössze a következő lekéréskor nem file cacheből, hanem dinamikusan
szolgálja ki a tartalmat majd frissíti a cache file-t.
Tehát ha van egymillió cache-lt tartalmad akkor mindíg ennyi fájlod lesz.
Persze lehet írni egy folyamatot ami törli a lejárt bejegyzéseket...
Sajnos kókányolni kell, mert nincs kapacitás átmigrálni a rendszert normális keretrendszerre, üzemeltetni viszont kell.
Ha még azután se volt kivégzés, hogy nem ment semmi, akkor talán az is megengedhető, hogy naponta/hetente/mittomén tervezetten nem megy pár percig.
Ha jól gondolom, akkor létrehozol egy fájlt, benne egy kisóverhedű fájlrendszerrel (minix?):
INIT:
dd if=/dev/zero of=/valahol/cacheA bs=1024 count=1 seek=${sok}M
mkfs.minix -i $josok /valahol/cacheA
mount -o loop /valahol/cacheA /cache-ing/konyvtar
/etc/init.d/szolgaltatas start
Dolgozgat, amíg el nem jön a szellőztetés ideje, akkor:
/etc/init.d/szolgaltatas stop
umount -f /cache-ing/konyvtar
rm -f /valahol/cacheA
goto INIT
Előnye, hogy mint a faék, hátránya, hogy tökönszúrja az INIT utáni lekérdezéseket.
Jó, rászántam egy percet, és megtaláltam, hogy valóban nem :(
Ha folyamatosan használja az összes fájlt (find ${CACHEDIR} -type f -mtime +1 nem sok fáljt ad vissza - remélhetőleg nem több egy napnál a refresh), akkor nincs más hátra mint előre, tényleg új fs kell neki.
Ha nem használja, akkor kell a végére egy | xargs rm :D
Nem szép megoldás, de üzemeltetni viszont kell...
Nem tudom mekkora site-ot uzemeltetsz, de szerintem legjobb lenne venni a faradsagot, es irni egy cron-t, ami idonkent kitorli a regi cache fileokat. Ha gyakran futtatod, akkor nem gyulnek ugy fel a fileok...
Mas FS-el szerintem csak halogatod a problema rendes megoldasat.
sub
--
A legértékesebb idő a pillanat amelyben élsz.
http://phoenix-art.hanzo.hu/
https://sites.google.com/site/jupiter2005ster/
Bár ez most nem segít rajtad, de csak megkérdezem: valami nagios féle eszközt nem használtok? Ha nem, akkor talán időszerű lenne elgondolkodni rajta...
Ugyan megelőzni nem fogja a hasonló eseteket, de legalább időben tud riasztani, ha valami fogyóban van a rendszeren.
(bocs, nagiost nem ismerem, BMC Patrolt használtam, de feltételezem, e téren van némi hasonlóság)
-tárgytalan-
-
Debian Squeeze
Van monitorozás, meg sms riasztás is.
De az Inodeok eddig kívül maradtak a látókörből...
Idén eddig 99.89% SLA-t sikerült elérni.
Nem vág földhöz pár óra kiesés, de pont egy ilyen apróságon elcsúszni :D
Sok takolas es ujrairas meg hasonlo helyett az esetleg nem jutott eszebe senkinek, hogy kiapcsolja a CI cachet?
----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™
Minek kikapcsolni? Ha gyorsitja az oldalt akkor annak legjobb maradnia. Torolni kell a regi cache fileokat. Nincs ebben semmi takolas, jo lett volna ha a CI szallit valami megoldast erre, de ha nincs akkor irni kell egyet.
Masszív cachelés nélkül használhatatlanul lassú az oldal.
Azt ne firtassuk, hogy rosszul van e megírva, biztosan lehetne jobban is.
Ez egy crawler, ami minden lekérésnél több weboldalt néz végig, és ebből állítja elő a választ
ha nem cachelsz, ~5s egy-egy response, ami nem túl felhasználóbarát.
~napi 100e kérés érkezik, szerencsére komoly csomósodás van, nagyjából mindenki ugyanazt keresi...
Még az jutott eszembe, hogy a tárhelybővítés simán mehetne egy sarokban heverő pécé leporolásával, és egy jól felinódolt fájlrendszerén lévő könyvtár NFS-en keresztüli bemountolásával.
A cache funkciót így is ellátja (mivel nem a lokál diszken vitatkozik a többi helyi processzel, nincs kizárva, hogy gyorsít is a jelenlegin), és az időszakos takarítás sem az igazi melót végző lemezt kerregteti hosszasan.