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> 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…

About the Author

Uwe

Uwe beschäftigt sich seit vielen Jahren mit Linux und Webdesign, seit 2006 benutzt er WordPress zum schreiben eines 'Tagebuchs'. Tätig ist Uwe als Webmaster und Netzwerkadministrator, er arbeitet und lebt seit 2001 in Oberhausen. In seiner Freizeit ist er viel mit dem Mountainbike und dem Fotoapparat unterwegs.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.