Sziasztok,
kérem segítségeteket a következő anomáliában (ha lehet csak az íron ötletet/tippes stb. akinek nagygépes solaris 10 OS alatt zona és mpm tapasztalata van), köszönöm.
Van egy SunT2000 masina amin az egyik zona a webserver ott az arhitektura miatt az apache MPM WORKERREL megy, illetve menne mert randomize(!) leáll a kiszolgálás a forkolt processek ott vannak, de nem szolgál ki semmit, a log elemzésben semmivel nem tudtam a jelenséget összekötni :-( A jelenség mindig más időpontban alakul ki, a háttérben semmi olyan nem fut ami a jelenséget okozná (awstats,indexelés,munin,nagios megy rajta, meg az apache+php nagy forgalommal).
Okozhatja-e a fenti jelenséget valami apache beállítás/nem beállítás? A php beállítása/nem beállítása okozhatja-e a fenti jelenséget? Illetve egyéb....???
- 2335 megtekintés
Hozzászólások
Amikor "lefagy" mutat valami normálistól eltérőt az mpstat?
Pl. megnövekedett spinning-mutex szám? (mpstat "smtx" oszlopa)
Ha igen, akkor lehet, hogy lockolási probléma áll fenn. Az Apache AcceptMutex direktívájával lehet beállítani a lockolási módszert: link
Mondjuk itt van a Solaris-ról egy megjegyzés, hogy képes elviselni, ha child processz mutex tartás közben meghal...
Érdemes mpstat, illetve vmstat kimenetét logolni 1-2 percig, amig fagyás van, és összehasonlítani a normál üzem közbeni értékekkel.
- A hozzászóláshoz be kell jelentkezni
Sajnos a rendelkezésre állás miatt nem állhat sok ideig, de megnézem, ma hajnalban állt le, és nyomtam egy restartot az apachenak, szóval nem sokáig állhat!
Nézem a linket és köszi a hozzászólást.
- A hozzászóláshoz be kell jelentkezni
Pár másodperc is sokat segíthet, annyit biztosan kibír a dolog. :)
Gyanús jelek lehetnek még a system-callok számának növekedése, magas system-time, illetve context-switch értékek.
Túl magas system call esetén a trapstat-al (pl. trapstat sleep 3) megtudható a system callok eloszlása.
Nem biztos, hogy apache probléma , lehet akár php, esetleg adatbázis (mysql?) is az oka.
- A hozzászóláshoz be kell jelentkezni
Az sql-t elvetném, igaz ezen a gépen van, de másik zonában.
- A hozzászóláshoz be kell jelentkezni
Csak abban az esetben felejtős, ha az sql zónának és az apache zónának külön dedikált cpu-setje van.
Ha nincs, akkor a cpu statisztika közös.
- A hozzászóláshoz be kell jelentkezni
Még nincs cpu csoportozás és még nincs definiálva az, hogy melyik szál/cpu mivel foglalkozzon, talán később.
Köszi az ötleteket Zwei!
- A hozzászóláshoz be kell jelentkezni
Szép időben az mpstat :
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 21 0 284 306 165 82 1 2 8 0 726 3 2 0 95
1 11 0 14 4 0 5 0 1 2 0 29 0 0 0 99
2 5 0 7 2 0 3 0 1 1 0 14 0 0 0 100
3 5 0 6 2 0 2 0 1 1 0 12 0 0 0 100
4 7 0 30 12 0 23 0 1 1 0 134 1 0 0 99
5 6 0 29 12 0 22 0 1 2 0 124 1 0 0 99
6 5 0 28 12 0 21 0 1 2 0 141 1 0 0 99
7 5 0 30 11 0 20 0 1 2 0 141 1 0 0 99
8 9 0 32 13 0 24 0 1 2 0 159 1 0 0 99
9 6 0 29 11 0 21 0 1 2 0 119 1 0 0 99
10 5 0 29 11 0 20 0 1 2 0 124 1 0 0 99
11 5 0 29 10 0 19 0 1 2 0 133 1 0 0 99
12 9 0 32 13 0 24 0 1 2 0 151 1 0 0 99
13 6 0 28 12 0 22 0 1 2 0 127 1 0 0 99
14 5 0 28 11 0 20 0 1 1 0 123 1 0 0 99
15 5 0 30 11 0 19 0 1 1 0 116 1 0 0 99
16 9 0 47 76 0 150 0 1 1 0 27 0 0 0 99
17 5 0 44 71 0 139 0 1 1 0 23 0 0 0 99
18 5 0 14 9 0 16 0 1 1 0 45 1 0 0 99
19 5 0 16 9 0 16 0 1 1 0 43 1 0 0 99
20 9 0 26 15 1 26 0 1 1 0 60 0 0 0 99
21 6 0 36 21 8 23 0 1 2 0 240 1 0 0 98
22 6 0 160 236 224 24 0 1 2 0 148 1 1 0 98
23 5 0 31 11 0 19 0 1 1 0 136 1 0 0 99
24 9 0 36 21 7 25 0 1 2 0 135 1 0 0 99
25 6 0 32 14 2 22 0 1 2 0 137 1 0 0 99
26 5 0 28 11 0 20 0 1 2 0 128 1 0 0 99
27 5 0 29 11 0 19 0 1 1 0 145 1 0 0 99
28 9 0 34 13 0 24 0 1 2 0 159 1 0 0 99
29 6 0 29 12 0 22 0 1 2 0 128 1 0 0 99
30 5 0 28 11 0 21 0 1 1 0 121 1 0 0 99
31 5 0 29 11 0 19 0 1 1 0 120 1 0 0 99
- A hozzászóláshoz be kell jelentkezni
Az első kimenetet felejtsd el!
Ha jól sejtem ez egy 32 thread-es T2000. Ez esetben az első 32 sor hanyagolható, mert ez a rendszerindítástól eltelt statisztikai átlagot adja.
5 darab 1 másodpercenkénti mintavételezéshez:
mpstat 1 5
A legelső felejtős, a további 4-et kell figyelembe venni.
- A hozzászóláshoz be kell jelentkezni
Jól sejted, az eddigi ötletek alapján nekiállok a fenti ötleteket logba szedni.
- A hozzászóláshoz be kell jelentkezni
ja, a trapstat és dtrace csak globális zónából futtatható....
- A hozzászóláshoz be kell jelentkezni
Tudom, nem gond. Csak a többi zona adatai is benne lesznek.
- A hozzászóláshoz be kell jelentkezni
A lokális zónában futtatott mpstat-ban is, mivel mint írtad közös cpu-kat használnak a zónáid.
- A hozzászóláshoz be kell jelentkezni
Ja, és trapstat helyett még használható a dtrace is:
# Syscall szám programonként
dtrace -n 'syscall:::entry { @num[execname] = count(); }'
# Syscall szám syscallonként
dtrace -n 'syscall:::entry { @num[probefunc] = count(); }'
# Syscall szám processenként
dtrace -n 'syscall:::entry { @num[pid,execname] = count(); }'
(A Dtrace egysorosok Brendan Gregg oldaláról vannak)
- A hozzászóláshoz be kell jelentkezni
Közben kipróbáltam a coolstackes cuccot is, annál még siralmasabb a helyzet :-( Ráadásúl MPM Preforkkal megy és nem tudok más mpm-et használni.
http://cooltools.sunsource.net/coolstack/
- A hozzászóláshoz be kell jelentkezni
mérések mutatnak valamit?
- A hozzászóláshoz be kell jelentkezni
A coolstackessel nem mértem semmit ott alapvető gondok voltak (?!), a főoldalon kívül semmi oldal nem jött be a http://domain.tld/akarmi formában.
Ma volt egy néztem is az mpstatot, de a cronból futtatott 5 percenként kis script épp nem logolta le az állapotot:-(
Az awstat : Mon Pages : 44451 Hits : 300726 5.07 GB
A AcceptMutex posixsem beraktam, de szerintem ez nem jó választás?! Most a fcntl van mutex kezelőnek.
- A hozzászóláshoz be kell jelentkezni
"
Ma volt egy néztem is az mpstatot, de a cronból futtatott 5 percenként kis script épp nem logolta le az állapotot:-("
ha úgyis kézzel indítod újra, akkor előtte lefuttathatsz egy scriptet, amiben van ps, mpstat, meg esetleg trapstat
10 másodperc plusz állásidőt biztos kibír, viszont ha nem mérsz semmit a "fagyás" alatt, akkor biztos, hogy jóval lassabban oldod meg a gondot...
- A hozzászóláshoz be kell jelentkezni
Most volt egy ilyen : (a Load is felment 10 fölé)
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 205 0 404 323 182 77 7 2 0 0 397 92 2 0 6
1 0 0 2 11 0 5 6 2 0 0 0 71 0 0 29
2 35 0 505 27 0 37 3 9 0 0 182 46 0 0 54
3 2 0 15 22 0 34 2 3 0 0 72 13 0 0 87
4 0 0 0 8 0 7 2 1 0 0 0 40 0 0 60
5 4 0 4 6 0 11 0 1 3 0 265 1 1 0 98
6 2 0 165 6 0 10 0 1 0 0 13 0 0 0 100
7 243 0 317 30 0 45 7 2 2 0 2519 60 5 0 35
8 0 0 64 29 0 55 0 9 0 0 43 0 0 0 100
9 0 0 2 7 0 6 4 2 0 0 20 28 0 0 72
10 0 0 0 7 0 9 1 2 1 0 2 38 0 0 62
11 0 0 20 28 0 51 2 2 0 0 318 14 1 0 85
12 16 0 111 32 0 57 2 4 1 0 293 17 0 0 83
13 4 0 37 59 0 115 1 5 0 0 1314 3 0 0 97
14 6 0 124 17 0 34 0 5 0 0 296 2 1 0 97
15 1 0 68 35 0 65 1 4 0 0 153 1 1 0 98
16 0 0 28 145 0 288 1 2 0 0 218 4 5 0 91
17 3 0 37 119 0 239 2 3 0 0 280 6 0 0 94
18 0 0 68 18 0 35 0 4 1 0 51 0 1 0 99
19 2 0 3192 21 0 36 1 4 0 0 21 22 1 0 77
20 159 0 1 12 0 23 0 4 2 0 68 1 1 0 98
21 0 0 7 21 13 14 0 1 1 0 143 1 0 0 99
22 0 0 176 291 283 0 7 0 0 0 0 100 0 0 0
23 0 0 7 15 0 29 0 3 0 0 60 0 0 0 100
24 0 0 8 23 16 12 0 3 1 0 6 0 0 0 100
25 0 0 2 11 1 10 5 3 0 0 2 70 0 0 30
26 0 0 61 28 0 56 0 4 0 0 29 1 0 0 99
27 0 0 1 9 0 16 0 4 0 0 5 0 0 0 100
28 2 0 134 13 0 23 1 2 1 0 170 15 1 0 84
29 0 0 373 9 0 12 3 3 0 0 87 49 0 0 51
30 0 0 1 12 0 20 1 4 1 0 188 12 1 0 87
31 28 0 53 12 0 17 2 3 1 0 315 22 1 0 77
- A hozzászóláshoz be kell jelentkezni
Ez csúnya!
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 5 0 426 287 173 40 25 10 2 0 224 98 2 0 0
1 0 0 0 13 0 11 12 2 4 0 0 100 0 0 0
2 0 0 1 13 0 11 12 3 0 0 3 100 0 0 0
3 0 0 1 20 0 27 19 8 0 0 21 100 0 0 0
4 0 0 0 13 0 10 12 3 0 0 0 100 0 0 0
5 0 0 17 35 0 53 34 5 1 0 679 98 2 0 0
6 0 0 0 19 0 26 18 6 1 0 3 94 6 0 0
7 0 0 0 23 0 34 22 3 0 0 10 100 0 0 0
8 0 0 0 10 0 8 9 2 0 0 2 100 0 0 0
9 1 0 2 16 0 20 15 2 0 0 249 99 1 0 0
10 0 0 0 11 0 4 10 0 3 0 0 100 0 0 0
11 0 0 2 22 0 33 21 3 0 0 21 100 0 0 0
12 0 0 0 13 0 8 12 1 0 0 0 100 0 0 0
13 0 0 0 20 0 28 19 1 0 0 9 100 0 0 0
14 0 0 0 11 0 12 10 1 0 0 80 100 0 0 0
15 0 0 0 16 0 21 15 1 3 0 0 100 0 0 0
16 0 0 2 83 0 152 82 1 4 0 281 99 1 0 0
17 0 0 8 29 0 40 28 3 0 0 0 100 0 0 0
18 0 0 1 12 0 7 11 2 0 0 1 100 0 0 0
19 0 0 0 13 0 9 12 2 0 0 2 100 0 0 0
20 0 0 1 18 0 19 17 3 2 0 0 100 0 0 0
21 0 0 3 27 16 7 11 1 0 0 2 100 0 0 0
22 0 0 86 170 158 7 11 1 0 0 2 100 0 0 0
23 0 0 0 12 0 9 11 2 0 0 23 100 0 0 0
24 0 0 0 13 3 4 9 1 0 0 1 100 0 0 0
25 0 0 0 10 0 4 9 1 2 0 1 100 0 0 0
26 0 0 0 9 0 3 8 3 1 0 0 100 0 0 0
27 0 0 0 14 0 13 13 2 0 0 4 100 0 0 0
28 0 0 0 10 0 2 9 0 0 0 0 100 0 0 0
29 0 0 0 12 0 8 11 1 3 0 1 100 0 0 0
30 0 0 0 10 0 6 9 3 0 0 0 100 0 0 0
31 0 0 4 55 0 100 54 13 0 0 56 100 0 0 0
- A hozzászóláshoz be kell jelentkezni
Ez roppant furcsa.
Színtiszta user time, semmi system. Nincs context-switch, nincs mutex pörgés...
Valami deadlock szitura gyanakszom, valamelyik programban. (apache, php esetleg mysql).
Ugye ez nem az mpstat első kimenete?
- A hozzászóláshoz be kell jelentkezni
Én apache + php -ra gyanakszom. De nem tudom megfogni a dolgot :-(
Nem az első.
- A hozzászóláshoz be kell jelentkezni
A system-callok száma is piszkosul kevés...
Következő állásnál próbáld ki:
trapstat sleep 5 >trapstat.log 2>&1
Ez 5 másodpercig cpu-statisztikát fog gyűjteni. Viszonylag hosszú fájl lesz, ha kirakod valahova letöltöm és megnézem.
futtathatsz még egy "prstat -m" parancsot is
pl: prstat -m 1 5 >prstat.log
Ez szintén 5 mintát vesz 5 másodperc alatt.
Egy ipcs -a parancs kimenet is jöhet.
A 10-es load egyáltalán nem gáz, ez a szerver kb 20-25 ös load-ig még egészségesnek mondható. A load kb. a wait-queue ben levő processzek számával egyenlő. Amig ez a szám nem közelít a processzorszámhoz, addig önmagában a load nem jelez problémát. (Jelen esetben nem jelent semmi használható információt).
- A hozzászóláshoz be kell jelentkezni
Egyébként csináltál bármi oprendszer tuningot?
Itt van pár tipp
Nagy forgalmú site-oknál már kell állítani a defult oprendszer paramétereken, illetve a T2000 miatt is szokás állítani ezt-azt, a sok párhuzamos thread miatt.
- A hozzászóláshoz be kell jelentkezni
Egyenlőre még nem, ez alapján dolgoztam : http://www.sun.com/bigadmin/features/articles/open_source_stack.pdf
Kicsit homályos, hogy mi az ami jót tenne és mi az ami a kernel panic függvényt hívná meg!
Ismered? Köszi a tippeket Zwei :-)
- A hozzászóláshoz be kell jelentkezni
No, legyünk egy kicsit következetesebbek.
Azt javaslom, hogy csinálj egy scriptet, amit lefuttatsz az apache újraindítás előtt.
Pl:
#!/usr/bin/sh
ipcs -a >ipcs.log
mpstat 1 5 >mpstat.log &
vmstat 1 5 >vmstat.log &
iostat -Dxn 1 5 >iostat.log &
prstat -m -n 32 1 5 >prstat.log &
trapstat sleep 2 >trapstat.log &
lockstat sleep 1 >lockstat.log &
truss -o truss.log -f -p ` pgrep httpd | head -1` &
sleep 5
pkill truss
echo "Most lehet ujrainditani az apacsot"
A "truss"-nál a httpd-t írd át arra a processzre, ami az apache processze. (ha ez nem httpd lenne.)
Ez lefut kb 5 másodperc alatt, és begyűjt egy csomó hasznos infót.
Előfordulhat, hogy a lockstat pampog valami hibát, hogy elfogyott az adatterülete, de ez nem érdekes.
További kérdések az ügyhöz:
Milyen verziójú az apache és a PHP?
A php-t hogyan használod? mod_php, esetleg fastcgi-ként?
Valami php-opcode cache van használatban?
- A hozzászóláshoz be kell jelentkezni
Ezt már megírtam, pár dolgot beleraktam amiket írtál, ha megint előferdül akkor megy a log gyűjtés.
Apache : 2.2.4 Php 5.1.6
Mod_php
eAccelerator & Xdebug
- A hozzászóláshoz be kell jelentkezni
Nos, sikerült jutni valamire, vagy azóta nem jött elő a hiba?
- A hozzászóláshoz be kell jelentkezni
Azóta nem jelentkezett a hiba, köszi az érdeklődést :-)
Apacheval játszottam, kevés forkolt process és több theread illetve a mutex is be lett állítva, azóta lekopogom minden oknak látszik.
- A hozzászóláshoz be kell jelentkezni