ugrás a tartalomhoz

Adott időszakban lelassul a gép SOS

Dzsozef · 2008. Szep. 19. (P), 11.34
A szerver gép egész nap megfelelően működik, majd este 18-22 órág folyamatossan lelassul, majd ezután folyamatosan beindul. Az illető neves cég azt mondta levizsgálta a vonalat és mindent rendben talált részéről.
Ergo a hiba a szerverbe van illetve a mi felőlünk keresendő.

Mi oldalunkról azért nem értjük, mi lehet a hiba, mert napközbeni és esti látogatottság, leterheltség között gyakorlati különbség nincs.
Miközbe az oldal betöltés nappal max3-4 sec., addig este 20-40sec.
Ez nagyon drasztikusan lassúságú. Érthetetlen, ha semmi nem változik semmiben, akkor mitől változik a sebesség??,

Milyen hiba lehet a szerverünknek ami napközben szépen megy, az emlitett esti időszakban egyszerüen leáll.

Mit lehet és hogyan megnézni, esetleg kivülről valaki folyamatos lekérést végez? amit nem látunk, vagy virus? amit nem észlelünk, de ezek nappal is lennének, vagy...???
Nagyon hálássan megköszönném a segítséget.

Adatok:
Linux Debian, Apache, Mysql, php
Gép Intel szerver, proc. Intel core 2,33 duo, 4Gb Ram,
sávszél: 100Mbs
tarskereso.mediatop.hu

Majdnem minden kivánságát telejsítem, aki segít rávezetni, a megoldásra.
Köszönettel várom a megoldás írányú válaszokat.
‹ WAMP - link nem működik Tartalom és motor csere. ›
 ■
1

Load?

janoszen · 2008. Szep. 19. (P), 12.25
Nem lehet hogy szimplán rázuhan az este netező felhasználók terhelése? Különösképpen, ha olyasmit üzemeltettek mint AJAX chat vagy egy-két rosszul megírt MySQL query. A probléma az, hogy nehéz megmondani root hozzáférés nélkül, de néhány tipp:

- rkhunter, chkrootkit
- netstat -an --inet
- iptables végignézegetése (ugye nincs nagyon sok rule egy chainben?)
- Ugye van saját, optimalizált kernel?
- Ugye gzipelve és megfelelő cache headerekkel szolgáljátok ki a statikus fájlokat? (ld firebug yslow extension)
- Nézegessétek a logot, cpu loadot, memória-használatot, swap műveleteket.
- MySQL terhelés? (Főleg CPU, de disk is.)
- Mit csinál a MySQL?
- Találjatok valakit, aki átnézegeti nektek a gépet (nem lesz feltétlenül olcsó).
2

A probléma a log!!!

Dzsozef · 2008. Szep. 19. (P), 15.08
Úgy néz ki a log volt a probléma, mert óránként mentette a Mysql ezeket és így a normális lekérdezések mellett ez már sok volt.
Ráadásul 100 Mb ig töltött le és 7 napot tárolt.

Köszi a segítséget, de még a garantál működés majd este igazolódik. Mi bizakodunk.
Akkor visszatérünk az ügyre.

Addig is köszi

üdv: Dzsozef
3

Query log?

janoszen · 2008. Szep. 19. (P), 15.10
Query logról beszélünk? Azt kapcsoljátok ki éles szerveren, doksiban is le van írva. Ha meg MySQL-be loggoltok access logot, akkor sztem ezt a koncepciót gondoljátok újra. Vannak nagyon jó log aggregátorok és azokat valamikor nagyon későn éjszaka is lehet futtatni, úgyhogy nem zavarnak be.
4

A LOG is hiba volt, de

Dzsozef · 2008. Szep. 22. (H), 15.04
A LOG is hiba volt, de önmagában nem oldotta meg a problémát. A hiba maradt változatlan időszakonként, főképpen este 18-22 között bortzasztó lassú a sebesség.
internetcím: tasrkereso.mediatop.hu
Mi okozhatja a lassulást: proc leterheltség 50%
néha felugrik egy pillanatra csak 100 fölé is, de ez most sztem nem érdekes. Cash memoria 1.2 GB, free 49Mb, totál 2,5 Gb.
Sztem a hardwer megfelel, valami beállítás elsősorban a Mysql-re tippelünk, de nem tudjuk ott mit állítsunk.
Állítottuk a table Caschet fölemeltük 64-ről 1000-re, open table lekérés 750 miatt.
De ez sem segített.

Egy táblábol kérdezünk le, általába 4-5 mezőt, max 12000 soros adatbázis.
Kis lekeérdezések vannak így, de egy oldalon 15 lekérdezés.

Tudsz javasolni valamit?
Ma végzünk mérést és meglátjuk mi jön ki. MUNIN progi val.

-----------------------------------
/etc/mysql/my.cnf jelenlegi adatai:
skip-external-locking
[mysqld]
key_buffer = 34M
max_connections = 300
table_cache = 1000
max_allowed_packet = 16M
thread_stack = 128K
thread_cache_size = 8
max_connections = 300
query_cache_type = 1
query_cache_limit = 1M
query_cache_size = 48M

[mysqldump]
quick
quote-names
max_allowed_packet = 16M

[isamchk]
key_buffer = 16M
5

Összesen 5 chainben/2 rule

Dzsozef · 2008. Szep. 22. (H), 16.41
Összesen 5 chainben/2 rule (ftp,ssh, input,output, forward)

-Alap kernel van fönn.
"gzipelve és megfelelő cache headerekkel szolgáljátok ki a statikus fájlokat? (ld firebug yslow extension)" - Ez nem egészen tiszta.

Magas CPU terhelés nem tudni miért.

köszi a sok válaszokat:)
6

CPU load okozója megfogható

zila · 2008. Szep. 22. (H), 16.48
Magas CPU terhelés nem tudni miért.

Ez nem tiszta. A magas cpu terhelést látni a processzlistában. Ha megvan a processz, akkor jó eséllyel megvan a bűnös. Ha a magas cpu terhelést a mysql okozza, akkor nézzétek meg mivel foglalkozik éppen a szerencsétlen. Naplózzátok a lassú lekérdezéseket (slow query log), az adatbiztonsági naplózást kapcsoljátok ki a mysql-ben (ha be lenne kapcsolva...)
7

chkrootkit

Dzsozef · 2008. Szep. 22. (H), 16.50
A chkrootkit lefuttatam, amiszerint, látni kéne thread -et, PID-eket azt nem látok, ZÁRTAK, csak EXE kezdő sorok voltak egyebek mellett ez nagyon gyanus csak nem tudom mit lehet tenni.
8

Root

zila · 2008. Szep. 22. (H), 16.52
ugye rootként futtattad? Ha igen, akkor egy jellemző mintát bemásolhatnál ide a fórumba (ne az egészet! :)
9

Itt az EXE sor kivonat

Dzsozef · 2008. Szep. 22. (H), 17.23
chkrootkit -x lkm
ROOTDIR is `/'
###
### Output of: ./chkproc -v -v -p 3
###
CWD 2626: /var/cache/bind
EXE 2626: /usr/sbin/named
CWD 2627: /var/cache/bind
EXE 2627: /usr/sbin/named
CWD 2628: /var/cache/bind
EXE 2628: /usr/sbin/named
CWD 2629: /var/cache/bind
EXE 2629: /usr/sbin/named
CWD 2630: /var/cache/bind
EXE 2630: /usr/sbin/named
CWD 2631: /var/cache/bind
EXE 2631: /usr/sbin/named
CWD 2980: /
EXE 2980: /usr/bin/python2.4
CWD 9888: /var/lib/mysql
EXE 9888: /usr/sbin/mysqld
CWD 9889: /var/lib/mysql
EXE 9889: /usr/sbin/mysqld
CWD 9890: /var/lib/mysql
EXE 9890: /usr/sbin/mysqld
CWD 9891: /var/lib/mysql
EXE 9891: /usr/sbin/mysqld
CWD 9893: /var/lib/mysql
EXE 9893: /usr/sbin/mysqld
CWD 9894: /var/lib/mysql
EXE 9894: /usr/sbin/mysqld
CWD 9895: /var/lib/mysql
EXE 9895: /usr/sbin/mysqld
CWD 9896: /var/lib/mysql
EXE 9896: /usr/sbin/mysqld
CWD 9901: /var/lib/mysql
EXE 9901: /usr/sbin/mysqld
CWD 9948: /var/lib/mysql
EXE 9948: /usr/sbin/mysqld

CWD 10618: /
EXE 10618: /usr/bin/python2.4
CWD 10619: /
EXE 10619: /usr/bin/python2.4

---------------------------
Nehéz ügy, mert a CPU 40-60 között van, aközbe is jó az odal betöltés., van hogy nem. De közbe egy pillanatra fölugrik 100 fölé is és vissza esik gyorsan.
A slow-log -ban nincs semmi, de ha engedélyezem a "log-queries-not-using-index" -et, akkor egyfolytában pörög. (kb. 3Mb méretű lett 2 perc alatt és megy tovább )
11

Indexek?

janoszen · 2008. Szep. 22. (H), 18.35
Nu, hát nézd meg, hogy mik azok a queryk amik nem használnak indexeket. Valszeg ott lesz a hiba.
12

Query kérdés

Dzsozef · 2008. Szep. 22. (H), 19.48
Erre Én is gondoltam, bár annyira nem vagyok jó mysql-ban, de úgy tudom, hogy ilyen "kicsi" soroknál nem befolyásolhat ekkorát a lassításban (összesen 10-12 ezer sor), illetőleg vannak helyzetek, amikor csak lassíthatja.
Az a kérdésem, hogy célszerű-e minden egyes "where" utáni mezőre tenni indexet bármekkora is a tábla mérete?
Egyébként egyszerű lekérdezéseket használunk, azaz egyszerre csak egy táblából. (nincs join-olás)
Tudsz valami jó mysql-lekérdezés figyelőt, mivel a "mytop" és/vagy "mtop" nem mutatja az éppen aktuális össz. lekérdezéseket (csak néhányat)??
10

Rootként vagyok bent

Dzsozef · 2008. Szep. 22. (H), 17.24
Rootként vagyok bent
13

FELGYORSULT A GÉP

Dzsozef · 2008. Szep. 25. (Cs), 15.12
A lassúlás fő oka -a mester szerint is- a táblák index hiánya volt, mely a slow-query.log -ból derült ki.
Ezúttal is megköszönjük Proclub-nak a nagyon hatékony és csak a mátrixban láthattál volna ilyen gyors segítséget.

Üdv:
Dzsozef