Üdv!
Szerintetek leállhat az apache ha az access.log mérete túl nagy (mert nincs rotálva)?
- 1169 megtekintés
Hozzászólások
- A hozzászóláshoz be kell jelentkezni
simán elképzelhető.
pl. nyom egy fstat()-ot a log fájlra, és kap vissza egy EINVAL-t, amire meg azt mondja, hogy ez fatal error, és kilép.
persze ehhez kell
- egy béna programozó, aki szerint normális dolog fstat() = EINVAL esetén kilépni
- egy béna fordító, aki lefordítja a programot large file támogatás nélkül
- egy béna rendszergazda, aki hagyja, hogy 2GB-osra nőjön a logfájl.
- A hozzászóláshoz be kell jelentkezni
Teljesen biztos is, hogy így van, mi már belefutottunk ebbe.
Nginx és 64 bit sok más problémánkat megoldotta, ami ezzel volt kapcsolatos.
Más:
-Mi van, ha nem logfilerol, vagy nem apacherol beszélünk?
Ugyanis úgy tudom, ez nem csak az apache sajátja.
Jellemző másik példa a 32bit előnyeire:
Van egy static szerverünk, ami 2 Gb ram mellé kapott még hatot + bigmem -et. Ujra is lett forgatva az nginx, mégis képtelen az egész rendszer használni 4Gb -nál több ramot, holott átlag 30% iowait van és nagyon kellene, hogy használja a ramot...
Szerk: Egy hasonló,csak jóval nagyobb terhelésre kihegyezett szerverünk 14Gb RAM -ot teljesen kihasználja, a különbség csak a 64 bit.
die(DIE_HARD);- A hozzászóláshoz be kell jelentkezni
-Mi van, ha nem logfilerol, vagy nem apacherol beszélünk?
Ugyanis úgy tudom, ez nem csak az apache sajátja.
vannak máshol is béna programozók... :)
Ujra is lett forgatva az nginx, mégis képtelen az egész rendszer használni 4Gb -nál több ramot
honnan tudod, hogy képtelen?
- A hozzászóláshoz be kell jelentkezni
Látom. a saját szememmel, hogy unused. Ha a /dev/shm -et telerakod, az megy (tehát a bigmem support ok.)
die(DIE_HARD);- A hozzászóláshoz be kell jelentkezni
hát, ha unused, akkor nyilván azért van ez, mert senki nem akarja használni. talán az alkalmazásokkal lesz a gond...
javaslom a "while (1) malloc(4096);" ciklusmagra épülő programokat, ők gyorsan orvosolni fogják a betegséget :)
- A hozzászóláshoz be kell jelentkezni
Inkább ugy fest, hogy a 32 bites nginx nem tudja megcímezni. (Akarná az használni, mikor napi több millio olalletöltéshez kell kiszolgálnia minimum 20, max 80 elemet).
die(DIE_HARD);- A hozzászóláshoz be kell jelentkezni
a max 80 elem elfér ezek szerint kevesebb memóriában is, különben a file system cache enné meg a sok megmaradt ramot. de ugye nem eszi, tehát a használt fájlok adatterülete nem több pár GB-nál. akkor meg mire használná a sok memóriát az nginx?
- A hozzászóláshoz be kell jelentkezni
Bocsánat, rosszul fogalmaztam:
Ez az érték megszorzódik a userek számával (30k egyedi/nap) és az átlag meglévő képmennyiséggel (20)/user, illetve ezekhez tartozik egy-egy thumbnail is. Ez 1200000 kép maximum/nap (de minimum ennek a negyede).
die(DIE_HARD);- A hozzászóláshoz be kell jelentkezni
nevetni fogtok, de a nagy logfile alatt igazából azt értem, hogy nehezen hozza be az mcedit:)
szal ez egy 54MB-os log file volt. de nem tudom, hogy apache-nál mi számít nagynak.
egyenlőre nem látok mást, hogy miért állhatott le. Lehet, hogy szolgáltató csesződött valamit. jövőhéten úgyis költözök.
- A hozzászóláshoz be kell jelentkezni
nevetni fogtok, de a nagy logfile alatt igazából azt értem, hogy nehezen hozza be az mcedit:)
nem, azon nem tudunk nevetni, ha valaki mcedittel néz logfájlt... :(
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Apache szokott random segfaultolni néha, pláne nagy terhelés alatt. De ez nem nagy log.
Mcedit helyett a
tail-f $log
vagy a
cat $log | grep amitakarsz
javasolt.
die(DIE_HARD);- A hozzászóláshoz be kell jelentkezni