Optimierung einer mysql Query

  • Thread starter Thread starter Deleted member 4401
  • Start date Start date
D

Deleted member 4401

Guest
Hallo zusammen...;)
Habe Probleme mit slow queries (besser gesagt EINER slow query):
Code: 
# Query_time: 16  Lock_time: 0  Rows_sent: 3  Rows_examined: 9602
SELECT t.forum_id, t.topic_id, p.post_time
                        FROM nuke_bbtopics t, nuke_bbposts p
                        WHERE p.post_id = t.topic_last_post_id
                                AND p.post_time > 1217741769
                                AND t.topic_moved_id = '0';

Die Abfrage wird ausgeführt wenn sich ein User in meine Site einloggt und dann das Forum betritt, es werden die neuen Posts seit dem letzen Besuch ermittelt, die Abfrage wird hier gestartet:
Code: 
        // Obtain a list of topic ids which contain
        // posts made since user last visited
        //
        if ( $userdata['session_logged_in'] )
        {
                $sql = "SELECT t.forum_id, t.topic_id, p.post_time
                        FROM " . TOPICS_TABLE . " t, " . POSTS_TABLE . " p
                        WHERE p.post_id = t.topic_last_post_id
                                AND p.post_time > " . $userdata['user_lastvisit'] . "
                                AND t.topic_moved_id = '0'";
                if ( !($result = $db->sql_query($sql)) )
                {
                        message_die(GENERAL_ERROR, 'Could not query new topic information', '', __LINE__, __FILE__, $sql);
                }

                $new_topic_data = array();
                while( $topic_data = $db->sql_fetchrow($result) )
                {
                        $new_topic_data[$topic_data['forum_id']][$topic_data['topic_id']] = $topic_data['post_time'];
                }
		$db->sql_freeresult($result);
        }

Habe mein Problem schon bei karakas-online.de gepostet (mehr oder weniger spezialisiert auf phpnuke), aber die scheinen dort selbst gerade ziemliche Probleme mit ihrer Performance zu haben, also dachte ich dass mir vielleicht hier jemand helfen könnte die Abfrage irgendwie zu optimieren.
Ich habe dieses Problem komischerweise erst seit mehreren Tagen, tuning-primer.sh sagt dass alles i.O. ist, REPAIR TABLE habe ich auch schon laufen lassen...alles ohne Erfolg...:confused:
 
Hast du in den letzten Tagen irgendwas an der Kiste verändert? Update von php, php_nuke oder mysql?
 
Nein, ist Debian Sarge, und da ich nur die offiziellen Packages benutz(t)e ist das letzte Update für php/mysql schon eine ganze Weile her, phpnuke läuft ebenso schon länger mit der selben config. Ich hatte zwar durch tuning-primer.sh einige Änderungen an der mysql config vorgenommen, aber dies nur als Reaktion auf die slow queries...gebracht hat es aber nichts.
Hier meine config:

Code: 
# * Fine Tuning
#
key_buffer              = 8M
max_allowed_packet  = 16M
thread_stack            = 128K
#####edit#####
max_connections      =15
table_cache             = 200
thread_cache_size     =10
myisam_sort_buffer_size = 16M
join_buffer_size        =2M
read_buffer_size        =4M
low_priority_updates    =1
#
# * Query Cache Configuration
#
query_cache_limit       = 262144
query_cache_size        = 8388608
query_cache_type        = 1

edit:
Hm, habe jetzt mal von einem anderen Server die my.cnf rübergezogen und fahre den Service jetzt wieder mit den defaults. In der alten config fehlte komischerweise skip-networking, obwohl ich nicht denke dass dies die Ursache war.
Aber bis jetzt keine slow queries mehr seit etwa 1 Stunde...mal abwarten bis zur Hauptverkehrszeit am Abend.
 
Last edited by a moderator:
Nach ewiger Rumwurstelei bin ich zu der Erkenntnis gekommen dass das ganze wohl auf die stark gestiegene Besucheranzahl meiner Site zurückzuführen ist, habe jetzt mysql nice -20 verpasst und schon fluppts um einiges besser. :)
 
bad_brain said:
habe jetzt mysql nice -20 verpasst
Click to expand...
Ist ja wohl eher suboptimal, oder? Schon geschaut ob Indizes helfen?
Wird in die Tabelle viel geschrieben? In bestimmten Fällen ist InnoDB besser als MyISAM, wenn es darum geht, wenn in eine Tabelle viel geschrieben wird.
 
Ich hätte auch auf Indizes getippt.
So krasse Prioritäten sind Core-Prozessen vorbehalten. Speziell die Spalten, die in dem Query als Join-Kriterium herangezogen werden. (Am besten alle, die im WHERE auftauchen.)
Und auch checken, ob die Indizes auch benutzt werden - nicht nur, ob sie da sind.
 
Indizes sind gesetzt, allerdings muss ich zugeben dass meine SQL-Fähigkeiten noch recht begrenzt sind, wie kann ich checken ob diese auch benutzt werden?
Ich gehe jedoch mal davon aus dass sie benutzt werden da sie schon beim Anlegen der DB von phpnuke automatisch gesetzt wurden, CHECK TABLE förderte auch keine Probleme zutage.
In die Tabellen wird recht viel geschrieben, es handelt sich um ein recht gut frequentiertes Forum und in den beiden Tabellen sind die Topics und die Posts abgelegt (bbtonuke, phpnuke Port von phpbb2).

Natürlich ist nice -20 nicht gerade das Gelbe vom Ei, aber ich bin mit meinem Latein einfach am Ende, sämtliche Optimierungsversuche in Richtung mysql haben nicht den erwünschten Erfolg gebracht....bei den oben genannten Queries schnellen die I/O-waits immer noch in die Höhe...:confused:
 
Danke, habs mittlerweile gegoogelt...:)
Also soweit ich das beurteilen kann sieht da alles i.O. aus:
 
Ich bin jetzt kein großer mysql-Crack, aber hast Du mal ein
Code: 
Analyze table
drüber gejagt und die Performance verglichen?

--marneus
 
ANAYLYZE TABLE sagt mir nur dass alles ok und die Tabelle up to date ist.

Habe jetzt mal per Hand Indizes für die beteiligten Tabellen mit high cardinality erstellt, also jetzt MÜSSEN die Indizes ja eigentlich benutzt werden:



Öhm, also wenn ich mir das jetzt so recht anschaue: Kann es sein dass vorher überhaupt keine Indizes gesetzt waren?
 
Last edited by a moderator:
Hm, also ich glaube das wars...läuft jetzt wesentlich besser obwohl nice nur noch -5 ist.
Vielen Dank allerseits. :)
 
Also bis jetzt läuft alles problemlos, das ganze System läuft wieder als ob man die Handbremse gelöst hätte.
Habe den Verdacht dass bei dem Stromausfall bei s4y bzw. den dadurch bedingten harten shutdown die Tabellen beschädigt wurden. Aber war zumindest eine gute Chance ein wenig mehr über mysql zu lernen. :)
 
You must log in or register to reply here.
Back
Top