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
Performance-Problem der Datenbank
-
wneudeck -
23. April 2015 um 18:20 -
Erledigt
-
-
Das hat absolut nichts mit dem Wetterboard zu tun.
Du mußt dich mit dem Problem an die Blitzortung wenden.
Nebenbei, ich habe nichts von derartigen Dingen bei meiner Blitzortung. Alles im grünen Bereich. -
- Offizieller Beitrag
-
Hallo Patrick,
ja, ich denke schon, habe die Version 1.3
Musste, wie oben schon gesagt, meinen Beitrag nochmals überarbeiten. -
OK, Entschuldigung, dann habe ich den Beitrag falsch interpretiert.
-
@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.
-
-
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
-
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 kilometerswü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 Werner,
mit den ganzen PURGE-Einstellungen vom MyBO habe ich mich nie wirklich beschäftigt, ich benutze da die Defaulteinstellungen. Drum kann ich dir da auch nicht wirklich weiterhelfen.
cu Robo
-
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) -
Werner, die Einstellung für BO_PURGE_SIG_ALL habe ich auch.
Meine Datenbankgröße liegt um die 1,5 GB, dieser Wert bleibt bei mir aber
schon seit geraumer Weile relativ konstant. -
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. -
- Offizieller Beitrag
Es sei denn, hast einen vollen Server.
Wäre dann die Frage, ob man da etwas entschlacken kann, quasi nach einer bestimmten Zeit bzw. Größe automatisch.
-
Wäre dann die Frage, ob man da etwas entschlacken kann, quasi nach einer bestimmten Zeit bzw. Größe automatisch.
Dafür sind ja die Zeilen aus Werner seinem Beitrag (11) eigentlich da.