Člověk co rozumí MySql serveru

Ahoj, mám VPS a na něm apache, mysql... Mám trochu problém, že občas trvá úplně obyčejný sql dotaz třeba 4s. HW by neměl být přetížený, průměr mysql je 1,5dotazu/s. Na serveru běží několik webů na WP, a dvě phpBB fóra. Celková návštěvnost bude asi 1000-2000UIP/den, takže skoro nic... Pokud se najde člověk, který rozumí mysql serveru a byl by mi schopný poradit, tak bych byl velice vděčný :) Zde STAV MYSQL: http://faststone.rypi.cz/2010-01-18_200708.png

Treba optimalizovat SQL. Pokial chces, mozem s tym pomoct, staci na ICQ napisat.

Na prvni pohled bych si prosel indexy v tabulkach. (cervene radky ti to v te statistice radi) :)

Chybějící indexy a pak jsem tam zahlídll ještě malou vyrovnávací paměť pro tabulky.

MySQL slow query logMožná by stálo za to sem dát: cat /etc/my.cnf

Je to WP a phpBB, takže žádnej muj bastl. O tom, že to píše varování s indexmama vím, ale píše to i kamarádovi, co slow query nemá. Spíš sem to myslel na tu cahce, ale tomuhle ještě moc nerozumím. my.cnf zde: http://faststone.rypi.cz/2010-01-18_211319.png v Mysql slow logu mám dnes asi 20 dotazů, což je na mojí návštěvnost moc. 90% jich vypadá takto: # Time: 100118 17:30:42 # User@Host: S4RypiCz @ localhost [] # Query_time: 4 Lock_time: 0 Rows_sent: 0 Rows_examined: 0 SET insert_id=7351; INSERT INTO phpbb_posts (forum_id, poster_id, icon_id, poster_ip, post_time, post_approved, enable_bbcode, enable_smilies, enable_magic_url, enable_sig, post_username, post_subject, post_text, post_checksum, post_attachment, bbcode_bitfield, bbcode_uid, post_postcount, post_edit_locked, topic_id) VALUES (61, 117, 0, '85.161.177.102', 1263832238, 1, 1, 1, 1, 1, '', 'Stehlikov', '***krátký text příspěvku***', '3308396c7280f304bd517bd5ff6bbd4d', 0, '', '3u0x577k', 1, 0, 599); //EDIT: Z těch 20ti jsou jen 3 dotazy typu SELECT a všechny jsou v noci, takže je možný že to bylo v době záloh, či tak něco... Navíc jsou celkem složité/vracejí hodně výsledků. Ale přes den už tam jsou jen samý INSERT, případně UPDATE... # Time: 100118 1:38:48 # User@Host: BlogRypiCz @ localhost [] # Query_time: 3 Lock_time: 0 Rows_sent: 4 Rows_examined: 16 use BlogRypiCz; SELECT SQL_CALC_FOUND_ROWS wp_posts.* FROM wp_posts INNER JOIN wp_term_relationships ON (wp_posts.ID = wp_term_relationships.object_id) INNER JOIN wp_term_taxonomy ON (wp_term_relationships.term_taxonomy_id = wp_term_taxonomy.term_taxonomy_id) INNER JOIN wp_terms ON (wp_term_taxonomy.term_id = wp_terms.term_id) WHERE 1=1 AND wp_term_taxonomy.taxonomy = 'post_tag' AND wp_terms.slug IN ('notebook') AND wp_posts.post_type = 'post' AND (wp_posts.post_status = 'publish') GROUP BY wp_posts.ID ORDER BY wp_posts.post_date DESC LIMIT 0, 6; # Time: 100118 1:45:39 # User@Host: BlogRypiCz @ localhost [] # Query_time: 3 Lock_time: 0 Rows_sent: 359 Rows_examined: 359 SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes'; # Time: 100118 2:20:41 # User@Host: KubaRypiCz @ localhost [] # Query_time: 4 Lock_time: 0 Rows_sent: 141 Rows_examined: 184 use KubaRypiCz; SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes';

Napsal Rypi;437850

Je to WP a phpBB, takže žádnej muj bastl. O tom, že to píše varování s indexmama vím, ale píše to i kamarádovi, co slow query nemá. Spíš sem to myslel na tu cahce, ale tomuhle ještě moc nerozumím.

my.cnf zde: http://faststone.rypi.cz/2010-01-18_211319.png

v Mysql slow logu mám dnes asi 20 dotazů, což je na mojí návštěvnost moc. 90% jich vypadá takto:

# Time: 100118 17:30:42

# User@Host: S4RypiCz @ localhost []

# Query_time: 4 Lock_time: 0 Rows_sent: 0 Rows_examined: 0

SET insert_id=7351;

INSERT INTO phpbb_posts (forum_id, poster_id, icon_id, poster_ip, post_time, post_approved, enable_bbcode, enable_smilies, enable_magic_url, enable_sig, post_username, post_subject, post_text, post_checksum, post_attachment, bbcode_bitfield, bbcode_uid, post_postcount, post_edit_locked, topic_id) VALUES (61, 117, 0, '85.161.177.102', 1263832238, 1, 1, 1, 1, 1, '', 'Stehlikov', '***krátký text příspěvku***', '3308396c7280f304bd517bd5ff6bbd4d', 0, '', '3u0x577k', 1, 0, 599);

//EDIT:

Z těch 20ti jsou jen 3 dotazy typu SELECT a všechny jsou v noci, takže je možný že to bylo v době záloh, či tak něco... Navíc jsou celkem složité/vracejí hodně výsledků. Ale přes den už tam jsou jen samý INSERT, případně UPDATE...

# Time: 100118 1:38:48

# User@Host: BlogRypiCz @ localhost []

# Query_time: 3 Lock_time: 0 Rows_sent: 4 Rows_examined: 16

use BlogRypiCz;

SELECT SQL_CALC_FOUND_ROWS wp_posts.* FROM wp_posts INNER JOIN wp_term_relationships ON (wp_posts.ID = wp_term_relationships.object_id) INNER JOIN wp_term_taxonomy ON (wp_term_relationships.term_taxonomy_id = wp_term_taxonomy.term_taxonomy_id) INNER JOIN wp_terms ON (wp_term_taxonomy.term_id = wp_terms.term_id) WHERE 1=1 AND wp_term_taxonomy.taxonomy = 'post_tag' AND wp_terms.slug IN ('notebook') AND wp_posts.post_type = 'post' AND (wp_posts.post_status = 'publish') GROUP BY wp_posts.ID ORDER BY wp_posts.post_date DESC LIMIT 0, 6;

# Time: 100118 1:45:39

# User@Host: BlogRypiCz @ localhost []

# Query_time: 3 Lock_time: 0 Rows_sent: 359 Rows_examined: 359

SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes';

# Time: 100118 2:20:41

# User@Host: KubaRypiCz @ localhost []

# Query_time: 4 Lock_time: 0 Rows_sent: 141 Rows_examined: 184

use KubaRypiCz;

SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes';

Co zkusit tu položku table_cache zvětšit (musíš také odstranit #)

Napsal Rypi;437850

Je to WP a phpBB, takže žádnej muj bastl. O tom, že to píše varování s indexmama vím, ale píše to i kamarádovi, co slow query nemá. Spíš sem to myslel na tu cahce, ale tomuhle ještě moc nerozumím.

my.cnf zde: http://faststone.rypi.cz/2010-01-18_211319.png

v Mysql slow logu mám dnes asi 20 dotazů, což je na mojí návštěvnost moc. 90% jich vypadá takto:

# Time: 100118 17:30:42

# User@Host: S4RypiCz @ localhost []

# Query_time: 4 Lock_time: 0 Rows_sent: 0 Rows_examined: 0

SET insert_id=7351;

INSERT INTO phpbb_posts (forum_id, poster_id, icon_id, poster_ip, post_time, post_approved, enable_bbcode, enable_smilies, enable_magic_url, enable_sig, post_username, post_subject, post_text, post_checksum, post_attachment, bbcode_bitfield, bbcode_uid, post_postcount, post_edit_locked, topic_id) VALUES (61, 117, 0, '85.161.177.102', 1263832238, 1, 1, 1, 1, 1, '', 'Stehlikov', '***krátký text příspěvku***', '3308396c7280f304bd517bd5ff6bbd4d', 0, '', '3u0x577k', 1, 0, 599);

//EDIT:

Z těch 20ti jsou jen 3 dotazy typu SELECT a všechny jsou v noci, takže je možný že to bylo v době záloh, či tak něco... Navíc jsou celkem složité/vracejí hodně výsledků. Ale přes den už tam jsou jen samý INSERT, případně UPDATE...

# Time: 100118 1:38:48

# User@Host: BlogRypiCz @ localhost []

# Query_time: 3 Lock_time: 0 Rows_sent: 4 Rows_examined: 16

use BlogRypiCz;

SELECT SQL_CALC_FOUND_ROWS wp_posts.* FROM wp_posts INNER JOIN wp_term_relationships ON (wp_posts.ID = wp_term_relationships.object_id) INNER JOIN wp_term_taxonomy ON (wp_term_relationships.term_taxonomy_id = wp_term_taxonomy.term_taxonomy_id) INNER JOIN wp_terms ON (wp_term_taxonomy.term_id = wp_terms.term_id) WHERE 1=1 AND wp_term_taxonomy.taxonomy = 'post_tag' AND wp_terms.slug IN ('notebook') AND wp_posts.post_type = 'post' AND (wp_posts.post_status = 'publish') GROUP BY wp_posts.ID ORDER BY wp_posts.post_date DESC LIMIT 0, 6;

# Time: 100118 1:45:39

# User@Host: BlogRypiCz @ localhost []

# Query_time: 3 Lock_time: 0 Rows_sent: 359 Rows_examined: 359

SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes';

# Time: 100118 2:20:41

# User@Host: KubaRypiCz @ localhost []

# Query_time: 4 Lock_time: 0 Rows_sent: 141 Rows_examined: 184

use KubaRypiCz;

SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes';

To není nic hrozného. Opravdu nemáš problémy s alokací paměti VPS?---------- Doplňující příspěvek odeslán v 23:00 ----------Zkus (my.cnf):table_cache=600 (povolit řádek #59, navýšit hodnotu)query_cache_size = 32M (řádek #65)

Paměti mám opravdu hodně volné, hodnoty zkusím navýšit :)Jinak nic hrozného to není, ale proč by mělo načtení stránky trvat třeba 5s? :)Zkusím hodnoty různě navýšit a pročíst manuál, kdyby něco, tak se ozvu. Zatím díky všem :P

Tak jsem to zkusil navýšit, ale nepomohlo. Teď mi došla ještě jedna věc. 95% slow queries jsou INSERT/UPDATE. Tam je cachování asi k ničemu... Nějaký nápad?

Btw. kolik zaznamu je v tabulce kam delas INSERT/UPDATE?

asi 2 000. Jde o tabulku phpbb_posts (phpBB3 fórum) Denně je vloženo třeba 100 záznamů. ale pouze 5 jich trvá déle než 2s, a to většinou 4s...

Napsal Rypi;440157

asi 2 000. Jde o tabulku phpbb_posts (phpBB3 fórum)

Denně je vloženo třeba 100 záznamů. ale pouze 5 jich trvá déle než 2s, a to většinou 4s...

ahoj, spise bych to tipoval na pretizeny ten VPS (ne ten tvuj, ale ten fyzicky HW na kterem ti to bezi) a to predevsim pretizene disky - hodne zapisu jinych zakazniku a na tebe se pak dostane az pozde. mas vystup sysstatu nebo neceho podobneho? pripadne jak vypada top v dobe kdy se generuji zapisy do slow logu? Pokud se problemy objevuji pri insert/update, bude se spise jednat o problem na systemu, nez v mysql. Ondrej -- www.tojeono.cz - webhosting pro profesionaly www.mam-web.cz - multihosting s CMS

Díky, to jsem si dříve taky myslel, byl jsem přesunut na jiný HW, avšak vůbec to nepomohlo. Dostal jsem taky screen z munina na HW, ale tam to taky nevypadalo, že by to bylo přetížený... (IOwait byl nízký...)Co se týče mé VPS, tak tam se load drží pod 0,5 a běží na virtuozzo. Takže jedině ten HW, s čím asi těžko něco udělám, když nepomohlo přesunutí... Napadlo mě zálohování ostatních VPS na stejném HW, ale dělá to i v časech, kdy žádné zálohování neběží.

Takhle opravdu těžko říct. Jestli máš SSH, tak: cat /proc/user_beancounters - uvidíš jak na tom opravdu tvůj VPS je mysqladmin -u -p version - základní údaje mysql -u -p mysql> show processlist; - procesy, co se děje během sql insert tail -f /var/log/mysqld.log - výpis logu Zkoušel jsi myisamchk?