Mysql akadások

Debian GNU/Linux

Sziasztok.

Van két Debian Lenny alatt futó LAMP kiszolgálónk, ahol az egyik gépen fut a Mysql szerver és mindkét gép ehhez az adatbázishoz csatlakozik. A gépek egy weboldalt szolgálnak ki, amit egy Drupal CMS hajt saját kiegészítőkkel.

A probléma, hogy szabálytalan időközönként az oldalak lekérése 20-30, vagy több másodpercre is megakad, néha pedig timeout-ol és a Drupal kiírja, hogy nem tudodd csatlakozni az adatbázishoz.
Mindeközben egyik gépen sincs jelentős terhelés, a processzor és disk használata elenyésző, a Mysql látszólag semmit nem csinál, 0% processzorterheléssel.

Top-al és mytop-al is folyamatosan figyelem, látszólag semmi sem történik, de a mytop is megakad ezekben az esetekben.
Slow query log bekapcsolva, egy-egy ilyen akadást követően nem látok benne változást.

Az adatbázis 3 táblát tartalmaz összesen 1,5GB méretben, a Mysql könyvtár egy raid10 tömbön van xfs fájlrendszerrel az alábbi opciókkal csatolva: rw,noatime,nodiratime,nodev,noexec,nosuid,logbufs=8,logbsize=256k

A Mysql konfig:


[mysqld]
user = mysql
pid-file = /var/run/mysqld/mysqld.pid
basedir = /usr
datadir = /var/lib/mysql
tmpdir = /tmp

default-character-set = utf8

port = 3306
socket = /var/run/mysqld/mysqld.sock
skip-locking

read_rnd_buffer_size = 1M
max_connections = 220
max_user_connections = 220
key_buffer = 320M
key_buffer_size = 320M
myisam_sort_buffer_size = 64M
join_buffer_size = 4M
read_buffer_size = 2M
sort_buffer_size = 3M
table_cache = 4000
open_files_limit = 8200
thread_cache_size = 128
interactive_timeout = 20
wait_timeout = 100
connect_timeout = 10
max_allowed_packet = 2M
max_connect_errors = 1000
query_cache_limit = 4M
query_cache_size = 80M
query_cache_type = 1
tmp_table_size = 128M
max_heap_table_size = 128M

concurrent_insert = 2
low_priority_updates = 1

long_query_time = 2
log-slow-queries = /var/log/mysql/mysql-slow.log
log-queries-not-using-indexes

A saját tábláimra, plusz a Drupalban néhány általam sűrűben használt táblára létrehoztam a megfelelő indexeket, ezek gyorsaságával nincs is gondom.

A Mysql verzió: 5.0.51a-24+lenny3
Kernel: 2.6.26-2-amd64

Ha valaki találkozott már hasonlóval és tudna tanácsot adni, merre keresgéljek a megoldást illetően, azt nagyon megköszönném.

EIK: Zoli

  • 2187 megtekintés

( petya | 2010. 06. 03., cs – 16:38 )

query_cache_size=0

A query cache ugy altalaban eleg bugos, millio ilyen rejtelyes mysql elakadast oldott mar meg a query cache kikapcsolasa.

Köszönöm, kipróbálom. Ez a teljesítményre nézve nem fog drasztikus hátrányt jelenteni?

Az előbb még annyit elfelejtettem írni, hogy amikor egy ilyen akadást követően egyszer csak elkezd normálisan működni, akkor egy pillanatra a mytop-ban egy csomó csatlakozási kérés jelenik meg. Gondolom ezek a hiba idején felhalmozódott kapcsolatok.

Üdv: Zoli

A query cache a kovetkezot csinalja:
Ha egy SQL ugy kezdodik case insensitiven, hogy sel, akkor csinal ra egy hasht es megnezi az adott hash-t a query cache-ben. Ha megvan, akkor nem futtatja le a selectet, csak eloveszi az eredmenyt a query cache-bol. Iraskor invalidalodik a query cache azon resze, ami az adott tablat erinti. Megnezni az allapotat a show status like 'Qcache%' paranccsal tudod, hitratet a Qcache_hits-bol es a Com_select-bol tudsz szamolni.

Ezek az eredmények:


+-------------------------+----------+
| Qcache_free_blocks | 15556 |
| Qcache_free_memory | 51108528 |
| Qcache_hits | 13539360 |
| Qcache_inserts | 800846 |
| Qcache_lowmem_prunes | 6387 |
| Qcache_not_cached | 114595 |
| Qcache_queries_in_cache | 27869 |
| Qcache_total_blocks | 71537 |
+-------------------------+----------+

+---------------+--------+
| Com_select | 887793 |
+---------------+--------+

Ha jól számoltam ez közel 94%-os hitrate-et jelent, ami elég jónak tűnik. Mindenesetre kipróbálom a javasolt változtatást, remélem megoldja a problémát.

Köszönöm a segítséget.

Üdv: Zoli

( crt | 2010. 06. 28., h – 13:57 )

Sziasztok!

Petya tanácsára a query_cache-t letiltottam, kb. két hétig teljesen jól működött. Már épp megírtam volna, hogy ez volt a megoldás, de múlt péntek óta megint megjelentek ezek az akadások, de most már sokkal többször és tovább tartanak (van úgy, hogy 1-2 percig is). Sem a mysql szerver, sem a gép újraindítás nem oldja meg a problémát még időlegesen sem.

A slow query log továbbra sem tartalmaz semmilyen bejegyzést ezekről az esetekről. Beállítottam, hogy fájlba naplózzon, ott sem látni semmilyen problémát. Azok a lekérdezések, amelyeket a leállás előtt és az elindulást követően a naplóban látok, gond nélkül lefutnak mysql konzolból, mindegyik lekérdezés indexelt tábla alapján történik.

Viszont egy érdekes dolgot tapasztaltam: egy ilyen megállás esetén a mysql konzolból kiadott lekérdezések pillanatok alatt rendben lefutnak. A Drupalok IP-n keresztül kapcsolódnak a mysql-hez, nem socketen, gondolom ez okozhatja az eltérést.

Ha valaki tud további tanáccsal szolgáln merre keresgéljeki, azt előre is köszönöm.

Zoli

Nem lehet, hogy tul surun csatlakozik a drupal, es kitiltja a mysql? Bar ha nem csinalsz ezzel semmit, akkor ugymaradna. max_connect_errors erteket allitanam be valami nagyon magasra. A masik, ami ilyet tud csinalni igy latatlanban az a table_open, table_close mutex. Nem lehet, hogy a table_cache erteked kicsi? Jo lenne beallaskori show processlist kimenetet latni.

Sikerült elkapni a processlistet, így néz ki: http://hup.pastebin.com/UZ1eRvMA

Úgy tűnik, valami a kapcsolódásnál nem lesz rendben. A max_connections értékét reggel felvettem 230-ra, eddig ebből 210 volt a maximálisan használt.

A table_cache-el kapcsolatosan jelenleg beállított értékek:
table_cache = 3500
open_files_limit = 7200
tmp_table_size = 256M
max_heap_table_size = 256M

A státuszban ez látszik:
Open_files 3577
Open_tables 2115

Köszönöm:
Zoli

mult heten szivtunk pont egy ilyet, dns/hosts file para lesz. 2 lehetoseged van.

1. tegyel a mysqld section-be egy skip-name-resolve sort es a mysql usereid a tablaban ip-vel legyenek azonositva, ne host nevvel

2. hosts file-ba/dnsbe vedd fel a csatlakozo gep nevet is

egyebkent too many connection-t kapsz a mysql-tol ilyenkor, azert varakoznak az oldalak.

Köszönöm mindkettőtöknek, úgy tűnik ez volt a probléma, most kb. egy órája hiba nélkül működik. Egyelőre még nem jelzem a téma címében, hogy [megoldva], nehogy korai legyen az öröm.

Viszont magát a jelenséget nem értem, mert eddig is minden csatlakozás IP alapján történt, a mysql usereket is IP alapján hoztam létre és február óta hiba nélkül működött a rendszer.

Köszönöm még egyszer.

Üdv: Zoli

Lehet pl. packet loss, nyilván, ha nem gépen belüli a connection.

Gépen belül - hacsak nem sikerült valami nagyon ütős tűzfal szabályt alkotni (pl. van iptables -m random, amivel könnyen random X százalékos packet loss-t lehet gyártani :-) - ez azért nem valószínű.

Én egyébként kidobtam az XFS-t, pont azért, mert nem tudta menedzselni az írási sávszélességet, és ha jobban meghajtottam írásokkal, akkor teleírta a memóriát, majd szinte minden megállt, amíg a kedves XFS ki nem írta a jó részét a teli puffereknek - és ezt ráadásul baromi lassan csinálta. Én mostanában ext4-re szavazok, bár az szívás, hogy az értelmes beállítások =/= default beállítások.

Gépen belül nincs korlátozás és a másik géppel is egy fizikailag külön kártyán vannak közvetlenül összekötve, ott sem határoztam meg a tűzfalban korlátozást.

Azért nem gondolom, hogy az XFS miatt lenne, mert amikor beáll egy percre, van időm nézegetni és 0% IO, 0-0.5 load van, processzor használat szinte semmi.

Üdv: Zoli

( Jason v | 2010. 06. 28., h – 15:14 )

nincs véletlenül fail2ban vagy valami bandwidth betartató modulod?

--
"SzAM-7 -es, tudjátok amivel a Mirage-okat szokták lelőni" - Robi.

( trey | 2010. 06. 28., h – 16:00 )

Az első, amit a helyedben megcsinálnék mindentől függetlenül az az InnoDB-re váltás. Drupal esetén a MyISAM fail. Főleg nagy terheléssel.

--
trey @ gépház