Dobře pojďme tedy dál.
MySQL byl samozřjmě první kde jsem začal hledat. Takže to běžně kontroluji přes mytop a zkouším to ladit podle doporučeních, která to generuje, ale nevidím tam žádný zásadní výsledek ať už nastavím cache jak chci.
Po tom všem hledání jsem zatím u toho, že je problém s výkonem disku a jak vidno, teď mě to vrací zpět k MySQL ( ostatně nic jiného tam v podstatě ani neběží, že?). Až na úroveň disku jsem se dostal, protože jsem hledal u které konkrétní TB -> souboru je problém. Jenže tady jsem skončil u toho kjournald.
http://forum.slicehost.com/index.php?p=/discussion/3790/high-io-wait-for-mysql/p1 http://forum.slicehost.com/index.php?p=/discussion/3373/x&page=1#Item_0 ?
- link jedna, tam už jsem jednou byl, ten příkaz je nefunkční, ale když se doplní chybějící 'command', tak už to k něčemu je. Momentálně mi to generuje počet tmp kolem 3 (0-5), uvídím co to bude dělat v okamžiku zpomalení.
mysqltunner za posledních pár dní říká že:
[OK] Temporary tables created on disk: 10% (22K on disk / 207K total)
[OK] Temporary tables created on disk: 16% (149K on disk / 912K total)
[OK] Temporary tables created on disk: 17% (198K on disk / 1M total)
[OK] Temporary tables created on disk: 16% (54K on disk / 322K total)
[OK] Temporary tables created on disk: 8% (134 on disk / 1K total)
Jenže to samozřejmě nic nevypovídá o tom, že by to nemohlo dělat problém.
Pokud si vyjedu sledování toho Created_tmp_disk_tables za posledních 24h, tak je to zhruba takto:
Created_tmp_disk_tables 447
Created_tmp_disk_tables 37
Created_tmp_disk_tables 30
Created_tmp_disk_tables 27
Created_tmp_disk_tables 27
... a tak podobně dál, už jsou jen počty 25 a méně, což mi nepřipadá tak moc.
Těch 447 je IMHO ze 03:28 ráno (už jsem neměl čas udělat skript, aby to zapisovalo i čas a dalo se to porovnat se záznamem z atop logu - dodělám), kdy se provádí kontrola kozistence replikace a provádí se kontrolní součty všech TB v té DB 5.75GB viz níže.
Fakt je, že tam (skoro) vždy nějaký příkaz ve stavu "create tmp table" visí, jenže já jsem udělal ten temp pro mysql už dříve na RAM disku ( 500M - je to málo? ) a :
- žádný rozdíl jsem tam nepozoroval
- nikdy se mi nepodařilo zjistit, že by se tam nějaký soubor vytvořil
(ano neznamená to, že by se tam nevytvářely - dá se to nějak zjisti?)
- od té doby co jsem ten RAM disk zrušil ( cca týden ) jsem nepozoroval žádnou změnu
tmp_table_size bylo nastaveno na 400MB a TB na které to asi nejčasteji visí má 1,9GB, tak je možné, že se to míjelo účinkem
-link dva řeší bug v MySQL, což teď už snad nehrozí a nastavení/vyladění pro Drupal.
Důležité je, že tmp_table_siz je limitování max_heap_table_size, takže to zkusím nastavit
ramfs size=5GB
mp_table_size = 3GB
max_heap_table_size = 5GB
OK - můžou to být tmp tables (všechno tomu nasvědčuje), budu tímto směrem pátrat dál.
/**********************************************************************************************/
Problem muze byt jak s vykonem disku nebo filesystemu, tak s mysql.
Zacal bych revizi konfigurace mysql ... muzete nastinit kolik mate v mysql celkem dat a indexu s rozdelenim na konkretni storage engine ?
Ta konkretni tabulka pouziva jaky storage engine ?
Pokud se bavime o innodb, jakou verzi pouzivate ? Mate vse v jednom souboru nebo pouzivate innodb_file_per_table ? Jaky je innodb_file_format ? Delal jste nekdy defragmentaci tech dat uvnitr tabulek ( predevsim u innodb ten vykon muze velmi nahle degradovat prave diky vysoke fragmentaci ) - takze s tim bych mozna zacal - je to nenasilne,snadno proveditelne a je relativne pravdepodobne, ze to pomuze.
A k diskum:
iostat -x 1 v dobe zapisu dat do tabulky
- v MySQL v "hlavní" DB je je 5,75GB / 250 tabulek
- největší TB jsou 1,9G; 641M; 510M; 467M; 224M; pár 1xxM a dál už jen desítky M
- TB 1,5GB na té to myslím nejčastěji visí a je také nejpoužívanější - položky jednotlivých nákupů
- v této hlavní DB je všechno v MyISAM, protože žádné vlastnosti InnoDB nepoužíváme
v tom je také trochu problém protože většina parametrů pro ladění výkonu začína innodb_
Pokud jsem hledal důvody proč použít MyISAM/InnoDB, tak se má za to, že MyISAM by měl být rychlejší a dostačující pro malé DB.
Novější verzi DB na kterou to chceme postupně překlopit již v InnoDB máme, ale zatím se to nepoužívá, nicméně nastavení je takové aby se pro každou TB používal samostatný soubor.
innodb_file_format = Barracuda
innodb_file_per_table = 1
Občas provádím repair a optimize tables, ale nedá se to kvůli replikaci master - master dělat automaticky.
Momentálně mi phpMyAdmin hlásí, že je 5 tabulek Overhead, ale jsou to naprosto nezajímavé TB a je to v řádech stovek bytů.
Navíc i když to provedu tak vzápětí mysqltunner stejně hlásí, že "[!!] Total fragmented tables: xx" :-( .
iostat jsem zkoušel, ale stejně se z něj víc než to že je vytížený /dev/sdb1 nedozvím.
/**********************************************************************************************/
Ten virtuál má disky na nějakém disku takže disky toho pc ne disky toho virtuálu.
Jasně, proto jsem psal, že VMWare píše, že jsou OK.
No mohl bych to ještě zkusit z konzoly toho VMWaru, ale obávám se, že tam se nic víc nedozvím a mementálně se tam ani nedostanu (vzdálené datové centrum, firewally).
Jinak zatím děkuji za nápady pátrám dál a dám vědět, ale příští týden jsem pryč, na lepším :-D.
10 Odpovědí
2521 Zhlédnutí