[Megoldva] Nem tudok írni a lemezre mert televan, pedig nem. Rejtély

Fórumok

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]

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á...

Á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

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...

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)

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™

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.