MySQL Basteleien

Schon länger nervt mich, dass mein Webserver gelegentliche „Aussetzer“ hat, wenn ich mehrere WordPress-Artikel „gleichzeitig“ bearbeite. Bisher hatte ich es immer auf unzureichende Performance des Apache-Dienstes geschoben. Heute fiel mir auf, dass wohl auch der MySql-Server nicht ganz unbeteiligt ist. Tatsächlich zeigte die Anzeige des (MySql-)Server-Status, dass ich an einigen conf-Einträgen spielen könnte/sollte.

...
mysql&gt; SHOW VARIABLES  WHERE Variable_name LIKE "%tmp_table_size%";
+----------------+----------+
| Variable_name  | VALUE    |
+----------------+----------+
| tmp_table_size | 16777216 |
+----------------+----------+
1 ROW IN SET (0.00 sec)
...

Einige der Parameter in der /etc/mysql/my.cnf sind noch an den extrem ‚unter-bemittelten‘, ehemaligen VServer angepasst und hätten wohl schon vor längerem zum Teil deutlich erhöht werden können.

...
#
# * Fine Tuning
#
###key_buffer             = 16M #alt
key_buffer              = 128M
 
###key_buffer_size
key_buffer_size         = 64M
 
###max_allowed_packet     = 16M #alt
max_allowed_packet      = 16M
 
###table_cache
table_cache            = 256
 
thread_cache_size       = 8
 
thread_stack            = 192K
 
#
# * Query Cache Configuration
#
query_cache_limit       = 1M
 
#query_cache_size        = 16M #alt
query_cache_size        = 64M
 
###tmp_table_size
tmp_table_size          = 512M
 
...

Google fand auch noch einen kurzen Artikel zur Performance-Steigerung. Nach dem Aktivieren der log-slow-queries-Option, zeigte sich schnell, dass viele Abfragen, die die Tabelle wp_ec3_schedule betreffen, arge Probleme haben.

...
# TIME: 121115 20:33:19
# USER@Host: wordpress[wordpress] @ localhost []
# Query_time: 6.461047 Lock_time: 0.000286 Rows_sent: 1 Rows_examined: 8633960
SET TIMESTAMP=1353007999;
USE wordpress;
SELECT SQL_CALC_FOUND_ROWS wp_posts.ID
 FROM wp_posts LEFT JOIN wp_ec3_schedule ec3_sch ON ec3_sch.post_id=id
 WHERE 1=1
   AND wp_posts.post_type = 'post'
   AND (wp_posts.post_status = 'publish'
  OR wp_posts.post_status = 'private')
   AND ((YEAR(wp_posts.post_date)='2012'
   AND MONTH(wp_posts.post_date)='10'
   AND DAYOFMONTH(wp_posts.post_date)='25')
  OR ((YEAR(START)='2012'
   AND MONTH(START)='10'
   AND DAYOFMONTH(START)='25')
  OR (START='2012-10-25 0:0:0')))
 GROUP BY wp_posts.ID
 ORDER BY wp_posts.post_date DESC LIMIT 0, 5;
...

Und tatsächlich zeigte eine entsprechende EXPLAIN-Abfrage mit dem oben gezeigten SELECT-Construct, dass es für die Tabelle ec3_schedule (aus dem Event Calendar 3 – Plugin) keinen passenden Index gibt. Den habe ich kurzerhand selber erzeugt und danach tauchte diese Tabelle nicht mehr im slow-Log auf.:

ALTER TABLE wordpress.wp_ec3_schedule
  ADD INDEX post_id (post_id)

Auch von der wp_posts-Tabelle gab es ein paar Einträge, die bei der Abfrage länger als drei Sekunden dauerten und auch hier fügte ich einen zusätzlichen Index hinzu:

ALTER TABLE wordpress.wp_posts
  ADD INDEX post_status_modified ( post_status , post_modified )

Dieser Index wude von der Datenbank auch sofort verwendet.:

id	select_type	table	type	possible_keys	key	key_len	ref	rows	Extra
1	SIMPLE	wp_posts	ref	post_status, type_status_date, post_status_modified	post_status_modified	22	const	9317	Using where

Nun bleibt abzuwarten, ob der Seitenaufbau in meinem Blog davon profitiert, ob die Einstellungen der Gesamt-Performance des Systems zuträglich sind oder ob ich den Server damit auf andere Weise überlaste…