Ab ca. 60 Downloads Mysql error: reading authorization packet

T

TAiS46

Registered User
Hallo,

ich habe 2 Server. Auf dem einen läuft eine Mysql Datenbank und auf dem anderen sind Dateien zum Download.
Der Download läuft über apache. Startet man einen Download, so wird ein eintrag in die Datenbank vorgenommen.

Ab ca. 60 gleichzeitigen Downloads bekomme ich jedoch die Meldung:
Warning: mysql_connect() [function.mysql-connect]: Lost connection to MySQL server at 'reading authorization packet', system error: 0 in

Dies kommt nach dem long-query timeout von der my.cnf einstellung!
Ich denke jedoch, das der Mysql Server versucht, Informationen an den Daten server zu schicken, er sie aber nicht verarbeiten kann?
Der Load des Server wo die Daten drauf sind ist auch nur auf 0.05 oder so!

Auszug der Prozessliste bei mysql:
| 384 | unauthenticated user | ns352167.ovh.net:37325 | | Connect | | Reading from net | |
| 386 | unauthenticated user | ns352167.ovh.net:37326 | | Connect | | Reading from net | |
| 390 | unauthenticated user | ns352167.ovh.net:37327 | | Connect | | Reading from net | |
| 393 | unauthenticated user | ns352167.ovh.net:37328 | | Connect | | Reading from net | |
| 396 | unauthenticated user | ns352167.ovh.net:37329 | | Connect | | Reading from net | |

Danke, Gruß Simon
 
Last edited by a moderator:
Ich tippe mal auf eine "Netzwerküberlastung".
Wenn Du 60 Downloads am laufen hast und noch die MySQL-Connection, die alle über die selbe Netzwerkkarte raus gehen, könnte entweder der TCP-Stack, die Karte selbst oder ein Switch/Router zum Flaschenhals werden.
Ich nehme an, Du hast ein PHP-Script welches den Download leitet.
Setze in der php.ini den "mysql.connect_timeout" höher (z.B. 60 Sekunden).
Und überprüfe, ob die MySQL-Connection geschlossen wird oder während der ganzen Übertragung geöffnet bleibt. Letzteres wäre nicht wirklich geschickt bei größeren Dateien... ;)

huschi.
 
Die Verbindung wird während des Downloads getrennt.
Also erst ein SELECT aus der Datenbank. Dann wird die Verbindung getrannt und die Datei an den Client geschickt (über php, richtig) und danach wird wieder eine INSERT gemacht. Er bleibt aber meist schon beim Select hängen.
mysql.connect_timeout würde ja auch nichts bringen oder?
Weil wenn ich long-query-time z. B. auf 20 habe, kommt direkt der Fehler nach 20 Sekunden. Es ist ja nicht immer so!
Ich denke das irgendwo ein Verbindungslimit drinne ist oder so.
 
Bring jetzt nicht zuviele Einstellungen durcheinander!
"long_query_time" ist auf Server-Seite einzustellen und hat nichts mit einem Timeout zu tun.
O.g. "connect_timeout" ist eine Client-seitige-Einstellung und gibt PHP mehr Zeit für den vollständigen Connect.

Ein Verbindungs-Limit gibt übrigens einen Fehler á la "too many connections".

huschi.
 
Oh sorry, habe nicht richtig nachgedacht.
mysql.connect_timeout = 60 steht beim Client bereits in der Config.
Wenn ich aber long_query_time einstelle, dann kommt nach denau den Sekunden die Meldung von php.
Also wenn long_query_time = 20 ist, kommt nach 20 Sekunden der Fehler mit:
Lost connection to MySQL server at 'reading authorization packet'
 
Nein, eine Lösung habe ich noch nicht, aber es sieht mir stark nach zu wenig ram aus!

Code: 
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 2194 nobody    15   0 92036  15m 4096 S    0  1.6   0:06.20 apache2
 2214 nobody    15   0 91800  15m 3984 S    0  1.5   0:05.85 apache2
 7073 nobody    16   0 91168  14m 4032 S    0  1.5   0:05.80 apache2
 4195 nobody    15   0 90856  14m 3976 S    0  1.4   0:05.43 apache2
 7706 nobody    15   0 89924  13m 3972 S    0  1.4   0:04.79 apache2
 7857 nobody    15   0 89836  13m 3996 S    0  1.4   0:04.92 apache2
 7520 nobody    15   0 89660  13m 4016 S    0  1.3   0:04.55 apache2
 6575 nobody    15   0 89748  13m 3984 S    0  1.3   0:04.64 apache2
 9224 nobody    15   0 89620  13m 3984 S    0  1.3   0:04.10 apache2
 8706 nobody    15   0 89468  12m 3972 S    0  1.3   0:03.95 apache2
 7743 nobody    15   0 89168  12m 4024 S    0  1.3   0:04.56 apache2
 7856 nobody    15   0 88996  12m 3980 S    0  1.2   0:03.61 apache2
 7893 nobody    15   0 88892  12m 3988 S    0  1.2   0:03.51 apache2
 7781 nobody    15   0 88812  12m 3988 S    0  1.2   0:03.84 apache2
 8179 nobody    15   0 88820  12m 3972 S    0  1.2   0:03.48 apache2
 8909 nobody    15   0 88612  12m 3980 S    0  1.2   0:03.15 apache2
 8290 nobody    15   0 88476  11m 4016 S    0  1.2   0:03.15 apache2
 7219 nobody    15   0 88036  11m 4020 S    0  1.2   0:03.43 apache2
 8983 nobody    15   0 88060  11m 3972 S    0  1.2   0:02.56 apache2
 4138 nobody    15   0 88044  11m 4008 S    0  1.1   0:02.87 apache2
 8291 nobody    15   0 87908  11m 3984 S    0  1.1   0:02.74 apache2
 9664 nobody    15   0 87796  11m 4016 S    0  1.1   0:02.34 apache2
 8705 nobody    15   0 87772  11m 3980 S    0  1.1   0:02.50 apache2
 7128 nobody    15   0 87748  11m 3972 S    0  1.1   0:02.81 apache2
u.s.w.

Gruß Simon
 
Mit zu wenig Ram sollte das nichts zu tun haben. Das Problem ist nicht trivial zu lösen und auch in mehreren Bug Reports auf mysql.com beschrieben.
Ich habe regelmäßig das gleiche Problem. Wir haben unsere Server bei Strato und wenn die Traffic Drosselung einsetzt, kommen keine MySQL Verbindungen zu dem jeweiligen Server mehr zu Stande!

Obwohl die Verbindung an sich nicht ausgelastet ist (Webseiten werden ausgeliefert, zwar etwas langsam aber sie kommen) kommen die Pakete von MySQL nicht mehr durch und der Verbindungsaufbau wird nicht abgeschlossen.
Ich habe alles mögliche ausprobiert, doch ich kann die Situation nicht verbessern. Zum Glück kann ich die Verbindung einfach wieder von dem gedrosselten 10Mbit auf 100Mbit hochschrauben. Dann geht alles sofort wieder!

Ich hoffe die kleine Erklärung hilft vielleicht!

Ach ja noch was: Für Downloads würde ich generell lighttpd einsetzen. Man kann ja ganz einfach den lighty als zweiten Webserver auf nem anderen Port laufen lassen und die Downloadlinks entsprechend anpassen. Die ca. 10 MB oder mehr die jeder Apache Prozess verbraucht sind bei 60 Downloads gleich 600MB, was man mit lighty auf 10MB insgesamt zurückstutzen kann.

P.S.: Jaja, ich weiß, so einfach kann man das nicht rechnen. Das hier nur mal als Beispiel ;)
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top