Sziasztok!
A köv problémám van egy debianos szerverrel.
Néhány naponta kb. negyed órára megáll a rendszer. Indítottam egy scriptet ami másodpercenként fájlba írja az uptime-ot, ez áll benne:
19:16:03 up 34 days, 22:03, 0 users, load average: 3.14, 1.14, 0.71
19:16:16 up 34 days, 22:03, 0 users, load average: 5.70, 1.79, 0.92
19:32:39 up 34 days, 22:20, 0 users, load average: 291.94, 581.83, 406.72
19:32:43 up 34 days, 22:20, 0 users, load average: 291.94, 581.83, 406.72
Tehát 16 percig annyira megáll a rendszer, hogy pár byteot sem tud a vinyóra írni másodpercenként. Többször előfordult már a dolog és mindig kb 15 percig tart. (Nem cronjob miatt van, mert az időpontok mások)
A szerveren Apache + PHP + MySQL 4 fut.
A syslogban a következő szerepel:
Feb 1 19:32:42 host kernel: oom-killer: gfp_mask=0x1d2
Feb 1 19:32:49 host kernel: DMA per-cpu:
Feb 1 19:32:49 host kernel: cpu 0 hot: low 2, high 6, batch 1
Feb 1 19:32:49 host kernel: cpu 0 cold: low 0, high 2, batch 1
Feb 1 19:32:50 host kernel: Normal per-cpu:
Feb 1 19:32:50 host kernel: cpu 0 hot: low 32, high 96, batch 16
Feb 1 19:32:50 host kernel: cpu 0 cold: low 0, high 32, batch 16
Feb 1 19:32:50 host kernel: HighMem per-cpu: empty
Feb 1 19:32:51 host kernel:
Feb 1 19:32:53 host kernel: Free pages: 3608kB (0kB HighMem)
Nem folytatnám, hasonlókkal van tele. Amit ebből kihámoztam az annyi, hogy az oom-killer kilövi a felelős processzt, de hogy mi okozza a gondot arra jelenleg csak tippem van, de egyelőre nem mondom, mert nem tudom rá a megoldást és kiváncsi vagyok más véleményekre is, hogy mi okozhatja a gondot.
Előre is köszönöm a segítséget!
- 1711 megtekintés
Hozzászólások
Mi volt a megoldás? Nekem most jött elő hasonló.
- A hozzászóláshoz be kell jelentkezni
Nekem is volt egy ilyen ma. Szerintem nagyon regen nem volt hasonlo.
Mindenesetre erdekes.
RAM: 2 GB
CPU: AMD Athlon64 3000+
Szerk:
Szerintem a MySQL szabadult el. Az okot nem tudom.
APIC error on CPU0: 40(40)
Ilyesmit nem irt elott a kernel a debug.log-ba?
- A hozzászóláshoz be kell jelentkezni
Ma nekem is elojot ez. Lehet valami globalis osszeeskuves hackelos cucc :))
------------------
Mindenre tudok magyarázatot találni, legfeljebb nem stimmel.
- A hozzászóláshoz be kell jelentkezni
Mi lehet a kozos pont?
CPU?
Alaplap?
Hasznaltok PHP Acceleratort?
- A hozzászóláshoz be kell jelentkezni
Alulmeretezett diszk I/O kapacitas + Apache elengedve "szabadon"
- A hozzászóláshoz be kell jelentkezni
Ez nalam akkor szokott tortenni amikor valami miatt szejjelforkolja az agyat az apacs.
--> MaxClients beallitast ellenorizzetek, aztan csokkentsetek...
Ami nalam berantotta tobb alkalommal az az apacs logging volt.
1. Valami barom elkezdte tomni hulyesegekkel a webszervert
2. Apacs elkezdett logolni mint az orult
3. apacsok elkezdtek IOra varni mert logloni akartak
4. egyre tobben lettek --> elfogyott a memoria mert tul magas volt a MaxClients.
Ez elofordult amiatt is, hogy a mysql blokkolt valami oknal fogva, es ezert torlodtak fel az apacsok.
Valami rendszermonitorozas hasznos ilyenkor. Nekem Cricket gyujti az apacs processzek szamat tobbek kozott.
Ha ez nincs a sysstat is tartalmazhat hasznos infokat.
- A hozzászóláshoz be kell jelentkezni
Hello,
nálam volt hasonló, a logokat már nem tudom megnézni, a rendszert már "lebontottam". Ott az volt, hogy a rendszert "örököltem", és - vesztemre - megbíztam a telepítést végző ismerősben, nem ez volt neki az első, de nem volt rutinos. A lényeg: sokáig csinált ilyet, és egyszer tök véletlen vettem észre, hogy nem volt felcsatolva a swap.... (partíció volt) Ezt orvosolva a hiba teljesen megszünt... :)
Hibáztam. :)
(magyarul elfogyott a memória az Apache/PHP/MySQL alól, a tünetek ugyanezek voltak: OOM killer, 100 feletti load-ok, néhány percig elérhetetlen gép)
a.
- A hozzászóláshoz be kell jelentkezni
ha oomkiller kigyilkol valakit, akkor az egesz processt kiteszi, nem?
tehat ha mysql a ludas, akkor az "hianyozni" fog a visszateres utan. ha apache a hibas akkor az.
--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
- A hozzászóláshoz be kell jelentkezni
Nálam apache process-eket gyilkolt ki, de a mysql mutatott nagy terhelest (munin szerint).
Apache process boven maradt meg, ugyhogy nem "hianyzott" :)
- A hozzászóláshoz be kell jelentkezni
Nekem erősen az a gyanúm hogy a mysql vmilyen nagyobb műveletet hajt végre és ezt nem kedveli a kernel.
Erősen gyanakszom arra hogy több memóriát fogyaszt, mysql és ettől van.
Debugolni hogy lehetne ?
Nekem 2.6.16-gentoo-r12 kernelem és MySql 5.0.26 -al jött elő.
- A hozzászóláshoz be kell jelentkezni
sysstat, cricket
Valami amivel tudod monitorozni mi tortenik. Ha egyik sem akkor egy rovidke script ami disk I/O, memoria es CPU terhelesi adatokat gyujt egy fajlba. Meg processz statisztikakat.
Vagy syslog szerverre. Mivel ha I/O problemad van a logot sem nagyon tudod kiirni...
A mysql-nel onmagaban nagyon nem szabadna elfolyatni az osszes memoriat.
Az apache ellenben "by design" ezt csinalja, ha magas a MaxClients ertek.
Persze mindez vak talalgatas adatok nelkul...
Milyen I/O schedulert hasznalsz?
Amikor remdszeresen nagy az ehezes (I/O starvation) a deadline jol johet.
- A hozzászóláshoz be kell jelentkezni