Performance-Problem der Datenbank

1. offizieller Beitrag

    Hallo,
    war jetzt lange nicht mehr hier. Habe nun vor kurzem festegstellt, dass speziell myblitzortung auf dem Server Performanceprobleme zeigt.
    Wenn ich beim cgi-debugger reinsehe, taucht immer wieder die Datenbank auf, die ich für myblitzortung verwende.
    Da kommen dann Meldungen wie
    Slow-Query-Time: 00:00:18: 'SELECT MAX(id) id FROM mybo_strikes WHERE time < '2015-04-21 11:31:04''
    Es scheint also, dass hier etwas nicht optimal läuft. Kann ein Experte hierzu was sagen?
    Ich bin nun hier nicht der Experte, aber ich verstehe sowieso nicht, was das "id" in Klammern (fett und rot gekennzeichnet) hier überhaupt soll
    Slow-Query-Time: 00:00:18: 'SELECT MAX(id) id FROM mybo_strikes WHERE time < '2015-04-21 11:31:04''
    Sorry, musste die letzte Zeile noch überarbeiten

    Einmal editiert, zuletzt von wneudeck (23. April 2015 um 19:10)

    Hallo Patrick,
    ja, ich denke schon, habe die Version 1.3
    Musste, wie oben schon gesagt, meinen Beitrag nochmals überarbeiten.

    Einmal editiert, zuletzt von wneudeck (23. April 2015 um 19:11)

    @wneudeck:
    Ich bin kein Experte! Für mich sieht MAX(id) nach einem Array aus (also eine Liste von Werten, die in einer Variablen abgespeichert ist - stark vereinfacht ausgedrückt).
    Wenn die Liste an Werten sehr groß ist, wird vielleicht eine vorgegebene Zeit überschritten und die Warnung "Slow-Query-Time" wird erzeugt.

    Vielleicht meldet sich ja noch ein Profi zu Wort ...

    Das kann hier aber etwas dauern, viele sind hier nicht mehr unterwegs in letzter Zeit. Ich lese mittlerweile auch regelmäßig im Forum bei Blitzortung.org mit. Vielleicht sollte man die Frage dort nochmal stellen, wenn sich hier nichts tut. Notfalls auf Deutsch, auch wenn da sonst alles Englisch ist.

    Viele Grüße

    Sven

    Hallo Robo,
    ich weiß nicht, ob ich ganz richtig verstanden wurde, denn mich irritiert hier
    Slow-Query-Time: 00:00:18: 'SELECT MAX(id) id FROM mybo_strikes WHERE time < '2015-04-21 11:31:04''
    das zweite "id"
    Ich würde es verstehen, wenn die Meldung so lauten würde
    Slow-Query-Time: 00:00:18: 'SELECT MAX(id) FROM mybo_strikes WHERE time < '2015-04-21 11:31:04''
    Was ich, und das ist ja die eigentliche Frage, nicht verstehe, wieso diese Abfrage so lange dauern kann.
    Die Tablle mybo_strikes ist 775 MByte groß und das sollte für mysql ja wohl kein Problem darstellen.
    Ich werde jetzt hier noch etwas abwarten, und dann mich vor allem an den Provider wenden bzw. dann bei blitzortung.org die Frage stellen.

    Hallo Werner,

    das zweite 'id' ist ein Alias, man könnte auch schreiben:

    SELECT MAX(id) AS id FROM ...

    Da Programmierer grundsätzlich nicht gerne viel schreiben, hat Tobias wohl das optionale 'AS' weggelassen. :)

    Der Query tut also nichts anderes, als die höchste ID zu suchen. Ich denke mal, dass der Zeitvergleich ziemlich zeitaufwendig ist.

    cu Robo :)

    Einmal editiert, zuletzt von robo (26. April 2015 um 00:11)

    Hallo Robo,
    danke für die Info. Das mit der Möglichkeit, das "as" wegzulassen, ist mir völlig neu, nun weiß ich es. Der Rest ist mir schon klar. Was mich trotzdem wundert, dass dies anscheinend so zeitaufwändig ist.
    Ich hoffe, ich darf jetzt aber noch eine Zustzfrage hier einbringen, wenn mal schon ein Fachmann zugange ist.
    Diese besagte Tabelle mybo_strikes war bei mir (vor ich manuell eingegriffen habe), ca 2 GByte groß (habe mich nicht verschrieben).
    Ich dachte immer, die Einstellung in der config
    define('BO_PURGE_ENABLE', true);
    sowie
    define('BO_PURGE_MAIN_INTVL', 6);
    define('BO_PURGE_SIG_NS', 24); //signals with no strike assigned
    define('BO_PURGE_SIG_ALL', 192); //all signals
    define("BO_PURGE_STRSTA_ALL", 24); //strike <-> stations table (very important!)
    define("BO_PURGE_STA_OTHER", 96); //station statistics: other (not yours)
    define('BO_PURGE_STR_DIST_KM', 1000); //distance for BO_PURGE_STR_DIST in kilometers

    würden das verhindern. Ich bin nun gerade dabei, zu überprüfen, ob die Tabelle weiterhin unkontrolliert anwächst.
    Am Rande:
    Dein Imapgen leistet mir vorzügliche Dienste, möchte nicht mehr darauf verzichten.

    Hallo Robo,
    ja, das ist schon klar. Ich stelle jetzt trotzdem mal folgende Bemerkung ein, vielleicht liest es ja noch jemand und kann was dazu sagen:
    die Anweisung
    define('BO_PURGE_SIG_ALL', 192); //all signals
    sollte ja nach 8 Tagen (nach 192 Stunden) alle Signale löschen und das tut sie nach meiner bisherigen Beobachtung nicht, was aber schlecht ist (habe das früher nie kontrolliert, bis die Tabelle unermesslich anwuchs)

    Hallo Dirk,
    danke für den Hinweis. Bei mir waren es eben, als ich nachsah, wie oben schon genannt, über 2 GByte. Und dass es da Performanceprobleme gibt, ist ja nachzuvollziehen. Ich werde es jetzt einfach eine Weile beobachten. Habe das bisher nicht gemacht, denn es lief ja. Nur wenn man dann eben ins Log schaut....
    Und es ist ja für einen Provider nicht toll, denn dort ist ja auf einem Server nicht nur ein User und letztlich "stehle " ich den anderen dann ja auch Performance, wenn eine Abfrage 18 Sekunden und mehr läuft.