4. Was braucht meine Datenbank?

Was braucht meine Datenbank?

  • R

    kann man ein mysql überhaupt so VERkonfigurieren dass er sich "aufhängt" ?

    Könnte das ein Ansatzpunkt sein ?

    http://www.mysqlperformanceblog.com/2009/04/15/how-to-decrease-innodb-shutdown-times/

    0
  • Administrator

    Es sind mehrheitlich nur MyISAM Tabellen im Einsatz. InnoDB wird nur für die neusten Tabellen für SquirrelMail und die Virtual Mail Accounts verwendet, welche aber kaum genutzt werden. Daher halte ich das für etwas unwahrscheinlich.

    Mir ist inzwischen allerdings bei Postfix die folgende Warnung aufgefallen:
    warning: mysql query failed: MySQL server has gone away

    Passiert z.B. teilweise wenn er die Virtual Alias Mappings abfragt, welche in der MySQL DB liegen. Wenn ich mich recht erinnere, war das meistens eher ein Hinweis darauf, dass der MySQL Server zu wenig Ressourcen hat. Was ich aber überhaupt nicht verstehen kann...

    Grüssli

    0
  • R

    MySQL server has gone away == Timeout. Der Client braucht zur Verarbeitung
    irgendwo zuviel Zeit. ( interactive_timeout oder wait_timeout werden überschritten )
    So kenne ich das aus meiner Praxis. Wie dabei das log aussieht und er ein
    query failed ausweist hab ich noch nicht nachgesehen. Wird bei Dir wohl ein
    anderer Grund sein, als ich es kenne.

    0
  • N

    "has gone away" muss überhaupt nichts heißen. Wenn du die Alias-Maps einfach nur sehr sehr selten abfragst, ist eben die Verbindung weg. Dann landet bei der nächsten Abfrage ein "has gone away" im Log, der Client verbindet sich neu und alles passt wieder.

    Dravere: Setz zuallererst mal ein munin oä. auf, schraube die Log-Verbosity hoch und protokolliere wann genau die DB nicht mehr reagiert. Alles andere ist blindes Rätselraten.

    0
  • N

    Btw, die InnoDB-Shutdownzeit-Geschichte ist schon lange uninteressant.

    0
  • Administrator

    nman schrieb:

    Dravere: Setz zuallererst mal ein munin oä. auf, schraube die Log-Verbosity hoch und protokolliere wann genau die DB nicht mehr reagiert. Alles andere ist blindes Rätselraten.

    Am munim beisse ich mir schon länger die Zähne aus. Ich krieg es nicht hin, dass die MySQL und Postfix Daten protokolliert werden. Bei der MySQL DB probiert sich munin ständig als nobody@localhost zu verbinden. Den User, welchen ich unter [mysql_*] in der munin-node Konfiguration angegeben habe, will er schlichtweg nicht verwenden. Es ist zum Haare ausreissen ... und überall steht was anderes, wie man dieses Problem lösen soll und nichts davon funktioniert.

    Ich probier es mal noch weiter mit diesem munin und falls ich es nicht hinbekomme, eröffne ich dann noch einen neuen Thread in TrudIT.

    Wie dem auch sei, für die DB habe ich noch ein paar sinnvolle Artikel gefunden, welche auch etwas weiterhelfen (falls mal jemand über diesen Thread stolpert):
    http://dev.mysql.com/doc/refman/5.5/en/optimizing-innodb.html
    http://www.mysqlperformanceblog.com/2006/05/30/innodb-memory-usage/
    http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/
    (auch die Kommentare lesen, sind auch hilfreich)

    Danke für die Hilfe.

    Grüssli

    0
  • N

    Dravere schrieb:

    Am munim beisse ich mir schon länger die Zähne aus. Ich krieg es nicht hin, dass die MySQL und Postfix Daten protokolliert werden. Bei der MySQL DB probiert sich munin ständig als nobody@localhost zu verbinden.

    Ich weiß gar nicht, wie spannend die Daten, die das MySQL-Plugin für Munin sammelt, überhaupt sind. Interessant ist RAM, Swap, IO, seltsame Logeinträge etc.

    Wie dem auch sei, für die DB habe ich noch ein paar sinnvolle Artikel gefunden, welche auch etwas weiterhelfen (falls mal jemand über diesen Thread stolpert):
    http://dev.mysql.com/doc/refman/5.5/en/optimizing-innodb.html
    http://www.mysqlperformanceblog.com/2006/05/30/innodb-memory-usage/
    http://www.mysqlperformanceblog.com/2007/11/01/innodb-performance-optimization-basics/

    Ja, die sind immer noch recht brauchbar. Wird aber wohl eher nicht die Ursache deiner Probleme sein. Dass ein MySQL-Server die von dir geschilderten Probleme hat, habe ich noch nie nur durch reine Fehlkonfiguration hinbekommen.

    0
  • Administrator

    nman schrieb:

    Ich weiß gar nicht, wie spannend die Daten, die das MySQL-Plugin für Munin sammelt, überhaupt sind. Interessant ist RAM, Swap, IO, seltsame Logeinträge etc.

    Bei RAM, Swap, IO und co kann ich allerdings nichts verdächtiges finden. Entsprechende Ausschläge stimmen mit Backups oder ähnlichen Cron Jobs überein. Und die DB ist auch nie zu diesen Zeitpunkten hängen geblieben. Interessant ist allerdings auch, dass die DB nun seit 3-4 Tagen problemlos läuft.

    Einzig was mich vielleicht überrascht, sind die >600 Prozesse, welche laut munin laufen und ps -ef | wc -l bestätigt dies. Wobei allerdings aktuell z.B. 481 der Prozesse php-cgi Prozesse sind, was Sinn ergibt. Zusätzlich scheinen jede Menge Prozesse für das Filesystem und den Software-Raid zu laufen. Und der Rest ist halt noch für den Mailserver, Content-Filter, cron und was es sonst noch so braucht. Scheint somit schon hinzukommen.

    nman schrieb:

    Ja, die sind immer noch recht brauchbar. Wird aber wohl eher nicht die Ursache deiner Probleme sein. Dass ein MySQL-Server die von dir geschilderten Probleme hat, habe ich noch nie nur durch reine Fehlkonfiguration hinbekommen.

    Naja, geht mir nicht nur darum mein Problem zu beheben. Geht mir auch darum rauszufinden, wie ich meine DB optimal konfiguriere. Da ich dies als etwas ansehe, was Hand in Hand läuft.

    Grüssli

    0
  • N

    php-cgi? Aber die Dinger laufen schon via FastCGI und nicht wirklich als CGI, oder?

    600 Prozesse ist schon eher brutal. 480 PHP-Prozesse ist nicht ganz wenig; ist die Site denn so stark frequentiert?

    0
  • N

    Dravere schrieb:

    Naja, geht mir nicht nur darum mein Problem zu beheben. Geht mir auch darum rauszufinden, wie ich meine DB optimal konfiguriere. Da ich dies als etwas ansehe, was Hand in Hand läuft.

    Versuch am besten, dir möglichst bald das hier zu holen:
    High Performance MySQL | ISBN: 1449314287

    0
  • Administrator

    nman schrieb:

    php-cgi? Aber die Dinger laufen schon via FastCGI und nicht wirklich als CGI, oder?

    Ja. Per Lighttpd mod_fastcgi eingebunden.

    nman schrieb:

    600 Prozesse ist schon eher brutal. 480 PHP-Prozesse ist nicht ganz wenig; ist die Site denn so stark frequentiert?

    Laut munin durchschnittlich 20 Zugriffe pro Sekunde. Wobei die Seite hat schon bessere Tage erlebt und die Einstellungen stammen noch aus dieser Zeit.

    Die Seite hat aktuell ca. 10'000 registrierte aktive Benutzer in der Woche. Gesamtzahl der aktivierten Benutzer beträgt ca. 250'000. Ist also schon was los 🙂

    nman schrieb:

    Versuch am besten, dir möglichst bald das hier zu holen:

    Hatte ich schon gefunden, aber ist das wirklich das richtige? Als ich die Beschreibung dazu las, kam es mir so vor, als wäre das mehr für grössere Serverkonstelationen gedacht. Heisst redundante Server in Clusters usw. Ich arbeite ja nur mit einem einzigen Root Server.

    Grüssli

    0
  • N

    Dravere schrieb:

    Hatte ich schon gefunden, aber ist das wirklich das richtige? Als ich die Beschreibung dazu las, kam es mir so vor, als wäre das mehr für grössere Serverkonstelationen gedacht. Heisst redundante Server in Clusters usw. Ich arbeite ja nur mit einem einzigen Root Server.

    Ganz kurz, weil wenig Zeit: Trotzdem genau das richtige Buch. Kaufen. 🙂

    0
  • Administrator

    nman schrieb:

    Ganz kurz, weil wenig Zeit: Trotzdem genau das richtige Buch. Kaufen. 🙂

    Ok, danke. Reicht leider nicht mehr für Weihnachten 😃

    Grüssli

    0
Anmelden zum Antworten