Was braucht meine Datenbank?

RED-BARON

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.

nman

"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.

nman

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

Dravere

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

nman

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.

Dravere

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

nman

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?

nman

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

Dravere

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

nman

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.

Dravere

nman schrieb:

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

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

Grüssli