Brauche Hilfe: "Lost connection to MySQL server during query"

B

Beeeee

New Member
Vorweg: Bitte entschuldigt, falls ich mich nicht klar genug ausdrücke, eine falsche Kategorie gewählt habe oder falls ich notwendige Angaben nicht gleich gepostet habe.

Ich habe bei Strato einen V-Server gemietet. Dort läuft
Plesk 8.1.1
PHP-Version: 5.1.2
MySQL-Version: 5.0.18
Server-Version: Apache/2.2.0 (Linux/SUSE)
GD-Version: bundled (2.0.28 compatible)

Auf diesem Server läuft unter anderem ein Forum von SimpleMachines.org (SMF in der aktuell gepatchten Version). Das Forum hat 130.000 Posts und läuft schnell und stabil.

Nun erhalte ich seit einiger Zeit beim Ändern eines Posts mit Anhängen diese Fehlermeldung vom mySQL-Server: Lost connection to MySQL server during query

Im Skript konnte ich diese Abfrage dafür verantwortlich machen:

Code: 
			$request = db_query("
				SELECT COUNT(*), SUM(size)
				FROM {$db_prefix}attachments
				WHERE ID_MSG = " . (int) $_REQUEST['msg'] . "
					AND attachmentType = 0", __FILE__, __LINE__);
			list ($quantity, $total_size) = mysql_fetch_row($request);
			mysql_free_result($request);

Die Tabelle "attachments", auf der dieser Select sich bezieht hat lediglich 700 Zeilen.

Führe ich den Select direkt auf der Konsole oder über phpMyAdmin aus klappt er einwandfrei und innerhalb von 0,0000004 Sekunden oder so.

Gegoogelt hab ich natürlich, die "Standard-Lösung" mit Höhersetzen von wait_timeout kann bei mir nicht die Lösung sein, da im Forum mit Sicherheit innerhalb von 8 Stunden eine Abfrage gemacht wird.

Okay, nun meine Frage: Wie kann ich dieses Problem lösen bzw. an die Sache herangehen?

Mein Ansatz: mySQL dürfte es nicht sein, da der Select ja über die Konsole einwandfrei läuft. Der Apache sollte es auch nicht sein, da er alle sonstigen Abfragen im Forum flüssig ausliefert. Der php-Interpreter vielleicht?

Vielen Dank schonmal für eure Hilfe!
 
Hi,

hast du mal geprüft, ob du ggf. an die RAM Grenze stößt?

Konsole + MySQL RAM-Verbrauch << PHP + MySQL RAM-Verbrauch

Bedenke, dass PHP Scripte durchaus nicht unerhebliche Menge RAM nutzen können je nach Einstellung.

Ist auch nur ein Schuss ins Blaue von meiner Kristallkugel. Sollte aber einfach zu testen sein.
 
Ja, ich habe das mit "top" geprüft. CPU- und Mem-Belastung waren weit unter 10%. Kann ich das noch anders überprüfen?

Ich habe das Forum zwischenzeitlich in einem Unterordner und einer neuen Datenbank frisch installiert, ohne die alten Datenbanken zu kopieren. Dort tritt der Fehler auch auf. Auf meinem Windows-PC und Xampp klappt das einwandfrei...:confused:
 
Sind die Attachments groß und in einem Blob in der Tabelle?
Oder ist in der Tabelle nur ein Verweis auf eine Datei?
 
Das ist es wohl! Ich habe eben im Plesk nachgeschaut: 2 GB hat wohl das "Blech", davon waren eben 98,8% genutzt. Von allen V-Servern auf dem Blech zusammen, bin ich da richtig?
 
elias5000 said:
Sind die Attachments groß und in einem Blob in der Tabelle?
Oder ist in der Tabelle nur ein Verweis auf eine Datei?
Click to expand...
Die Attachments sind kein Blob sondern liegen in einem eigenen Ordner. Daran kann es aber auch nicht liegen, ich habe eben das Forum (in mehreren Releaseständen) komplett neu aufgesetzt, der Fehler bleibt.

Meinen Apache habe ich so umkonfiguriert:

# StartServers 1
StartServers 5
# MinSpareServers 1
MinSpareServers 5
# MaxSpareServers 5
MaxSpareServers 10
# ServerLimit 10
ServerLimit 100
# MaxClients 10
MaxClients 100
 
Beeeee said:
Die Attachments sind kein Blob sondern liegen in einem eigenen Ordner.
Click to expand...
Womit sich meine Spekulation auf die Tabellengröße erübrigt haben dürfte.

Hast du MySQL mal das (Debug-)Loggen beigebracht und das resultierende Log angesehen?
Kannst du mal bitte alle Fehlermeldungen (PHP-Errors, MySQL-Errors) und ggf. interessante Loglines posten?
 
Sorry, wenn ich mich so "häppchenweise" melde, ich habe leider noch nicht so die große Erfahrung mit Linux.

Ich konnte eben über myPhpAdmin nachvollziehen, dass der mySQL-Server bei jedem Aufruf abgeschossen und dann wieder neu gestartet wird:
Code: 
Dieser MySQL-Server läuft bereits 0 Tage, 0 Stunden, 0 Minuten und 12 Sekunden.

Wie kann ich das Debug-Log von mySQL einschalten?

top gibt mir folgendes aus:
 

Attachments

  • top.gif
    top.gif
    7.1 KB · Views: 142
/var/log/mysqld.log:

Code: 
thd=0x8750980
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
Cannot determine thread, fp=0xb159ec3c, backtrace may not be correct.
Stack range sanity check OK, backtrace follows:
0x817dde7
0xb7fad7c8
0x85849e0
0x819d86b
0x819de1b
0x819f113
0x819fb7d
0xb7fa634b
0xb7de565e
New value of fp=(nil) failed sanity check, terminating stack trace!
Please read http://dev.mysql.com/doc/mysql/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved
stack trace is much more helpful in diagnosing the problem, so please do 
resolve it
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort...
thd->query at 0x86df2a8 = SELECT
			a.filename, a.attachmentType, a.ID_ATTACH, a.ID_MEMBER, a.ID_MSG,
			IFNULL(thumb.ID_ATTACH, 0) AS ID_THUMB, thumb.filename AS thumb_filename, thumb_parent.ID_ATTACH AS ID_PARENT
		FROM (smf_attachments AS a)
			LEFT JOIN smf_attachments AS thumb ON (thumb.ID_ATTACH = a.ID_THUMB)
			LEFT JOIN smf_attachments AS thumb_parent ON (a.attachmentType = 3 AND thumb_parent.ID_THUMB = a.ID_ATTACH)
		WHERE a.attachmentType = 0 AND a.ID_MSG = 2 AND a.ID_ATTACH NOT IN (0, 2)
thd->thread_id=39
The manual page at http://www.mysql.com/doc/en/Crashing.html contains
information that should help you find out what is causing the crash.

Number of processes running now: 0
071122 22:17:11  mysqld restarted
071122 22:17:11  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
071122 22:17:11  InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 0 4177555.
InnoDB: Doing recovery: scanned up to log sequence number 0 4177555
InnoDB: Last MySQL binlog file position 0 0, file name 
071122 22:17:11  InnoDB: Started; log sequence number 0 4177555
071122 22:17:11 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.0.18'  socket: '/var/lib/mysql/mysql.sock'  port: 3306  SUSE MySQL RPM
mysqld got signal 11;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.

key_buffer_size=16777216
read_buffer_size=258048
max_used_connections=3
max_connections=100
threads_connected=1
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 92783 K
bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
 
Beeeee said:
mysqld got signal 11;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured.
Click to expand...
Ist der MySQL aus distributionseigenen Paketen installiert?
Welche SuSE-Release hast du?

Poste mal den Output von:
Code: 
rpm -qa --last mysql\*
 
Last edited by a moderator:
Ja, das war die Standardinstallation von Strato, da hab ich nichts dazuinstalliert.

Ich erhalte folgende Ausgabe:

Code: 
package mysql* ist not installed
 
Code: 
mysql-bench-5.0.18-16                         Do 30 Aug 2007 14:52:54 CEST
mysql-devel-5.0.18-16                         Do 30 Aug 2007 14:52:53 CEST
mysql-5.0.18-20.8                             Do 30 Aug 2007 14:52:52 CEST
mysql-client-5.0.18-16                        Do 30 Aug 2007 14:52:49 CEST
mysql-shared-5.0.18-16                        Do 30 Aug 2007 14:52:32 CEST
 
Ist das so lange schon?
Irgendwelche Updates eingespielt nach dem 30.10.? Ne wichtige Lib oder so?
 
Nee, weil da die Strato-Hotline von abgeraten hat. Sobald ich ein Update vom Apache, PHP oder mySQL machen würde, würde Plesk nicht mehr funktionieren. Plesk wäre eben auf genau die ausgelieferten Pakete abgestimmt. Bei SW-Soft konnte ich im Forum das auch so nachlesen. Mal klappt es, mal nicht...
 
Strato-Support ... :mad:

Ich bin auch bei Strato, deswegen schimpfe ich nicht (Glashaus und so) ... Aber zumindest die Aussage für PHP und Plesk ist IMHO Quatsch. Ich habe in der SuSE 10.0 mit Plesk 8.x, über YAST PHP4 komplett deinstalliert und ein RPM mit PHP5 installiert.

Plesk lief weiter.

Gruß
Claus
 
Beeeee said:
Nee, weil da die Strato-Hotline von abgeraten hat. Sobald ich ein Update vom Apache, PHP oder mySQL machen würde, würde Plesk nicht mehr funktionieren. Plesk wäre eben auf genau die ausgelieferten Pakete abgestimmt. Bei SW-Soft konnte ich im Forum das auch so nachlesen. Mal klappt es, mal nicht...
Click to expand...
Du spielst also niemals Sicherheitspatches ein? aeh...
 
Würde ich ja gerne, ich bin mir dessen bewusst. Deshalb hab ich ja auch bei der Hotline mich deswegen erkundigt. Der Typi erschien mir recht kompetent und er riet dringend davon ab. Eben mit der Begründung, dass dann Plesk wohl nicht mehr funktionieren würde.

Ich lasse mich sehr gerne von euch belehren. Leider bin ich nicht so fit, dass ich auf Plesk verzichten könnte. Nur im Moment hab ich größere Probleme mit dem Absturz vom SQL-Server...
 
Ich habe zwischenzeitlich mit der Hotline telefoniert, hat wenig gebracht. Dies habe ich als E-Mail-bekommen:

Die von Ihnen beschriebene Verhalten deutet darauf hin, dass auf Ihrem V-PowerServer zu viel Speicher belegt wird. Die Speicherauslastung Ihrer Instanz können Sie sich in /proc/user_beancounters anzeigen lassen.
Click to expand...

Daraufhin habe ich wie vorgeschlagen mit einem Skript den freien Speicher überprüft:

VPS Speichernutzung==>
Momentan genutzt: 335,836 MB
Zugesichert: 259,375 MB
Maximal nutzbar: 791,281 MB
Click to expand...

Tut mir leid, wenn ich euch nerve. Heißt das jetzt, dass ich irgendwo zuviel Speicher nutze? Wenn ja, wo kann ich das sehen? Die Ergebnis der "top"-Abfrage ist weiterhin, wie in ein paar Posts vorher, weit unter 10% Speicherausnutzung.

Es ist jetzt wohl definitiv, dass der mySQL-Server abstürzt und daher diese Fehlermeldung bringt. Auch wenn ich die Forensoftware komplett neu in eine neue Datenbank installiere und dann die ensprechenden Skripte völlig ohne Last aufrufe stürzt mir weiterhin der mySQL-Server ab. In der Konsole und über phpMyAdmin hingegen arbeitet der mySQL-Server hingegen auch unter großer Last einwandfrei. Die Forensoftware selbst ist auch stabil und läuft ja auf meinem XAMPP unter Last gut.

Meine Vermutung: Irgendwas ist an PHP oder am Apache falsch eingestellt. Hat jemand noch eine Idee was ich überprüfen könnte?
 
You must log in or register to reply here.
Back
Top