MySQL - Too Many Connections

Netscape

New Member
Hi,

habe ein Problem mit dem ISPConfig (3.0.3.3 auf CentOS 6). Und zwar laufen die max_connections vom mysql server voll. Innerhalb von ein paar Stunden waren die 150 Connections vom ispconfig user belegt (sleep).

Das blockiert dann den ganzen mysql dienst.

Nun habe ich die max_connections auf 500 erhöht und es sind aber schon wieder 260 connections vom ispconfig user vorhanden.

Woran liegt das?
 

Till

Administrator
Du musst max_connections und max_user_connections auf 500 setzen, nur max_connections reicht nicht.

Alle Dienste auf dem Server nutzen den user "ispconfig" für die MySQL Verbindung, das was Du dort also siehts sind also nicht Verbindungen von ISPConfig mit der mysql DB sondern es sind Verbindungen von postfix, amavisd, pure-ftpd, courier bzw. dovecot. Die Verbindungen belegen keine weiteren Resourcen, d.h. ein paar Hundert verbindungen sind ganz normal und werden von den Diensten offen gehalten, da der Ressourcenverbrauch geringer ist als sie jedesmal neu aufzubauen. Daher sind die ja auch im "sleep" Status.
 

Netscape

New Member
Hab schon beides (max_connections und max_user_connections) auf 500 gesetzt.

Im Moment sind 270 Verbindungen im Sleep Modus.

Hat mich nur gewundert, dass so viele connections offen sind. Auf einem zweiten ISPConfig Server hatte ich diese "Probleme" nicht.

Und der Server läuft ja noch nicht mal produktiv. Hab nur keine Lust, dass der mysql dienst dann wieder abraucht, wenn die typo3 site live geht.
 

Till

Administrator
Du kannst Die mysql connections auch problemlos auf 1000 setzen wenn Du gnaz sicher gehen willst, da dies kein Resourcenproblem darstellt. Das Setup sollte aber auch so ausreichend sein wenn es nicht mehr als 100 - 200 vhosts auf dem Server sind.
 

Netscape

New Member
Aber warum braucht ISPConfig so viele connections? Auf dem Server ist nur ein vhost und der läuft noch nicht mal produktiv.

Jetzt bin ich bei 330 Connections.

Ich habe halt bedenken, dass selbst die 1000 irgendwann nicht mehr reichen.
 

Till

Administrator
Wie oben beschrieben, die connections sind nicht von ISPConfig sondern von den diversen Diensten auf Deinem Server. Der User heißt ispconfig, da es wenig Sinn macht 10 verschiedene User mit den gleichen Rechten zum Zugriff auf die gleieche Datenbank einzurichten und aktuell zu halten. Die meisten connections werden von postfix geöffnet, dann noch einige von amavisd, pure-ftpd dovecot, vlogger etc. Also alles ganz normal.

Ich habe halt bedenken, dass selbst die 1000 irgendwann nicht mehr reichen.

Also bei Produktivservern mit ca. 100 websites reichen 500 connections. Wenn Du also erstmal nicht mehr als 100 websites mit ein paar hundert mail accounts auf dem Server hast, dann sollte das reichen. Das Setup läuft so auf zehntausenden Servern weltweit, Du kannst also ganz sicher sein dass es einwandfrei funktioniert.

Was Du aber mal prüfen kannst ist ob vlogger einwandfrei geht, also ob Du web traffic im ISPConfig Interface angezeigt bekommst und ob es keine vlogger Fehler im globalen apache error.log gibt.
 

Netscape

New Member
Also heute bin ich schon wieder bei 480 Connections und somit schon wieder fast am 500er Limit, das ich gesetzt hab.

Die Traffic Anzeige funktioniert. Ich bekomme Daten angezeigt, ob die wirklich stimmen hab ich nicht kontrolliert.

Und auch sonst seh ich im Apache Log keine Fehler.

Die älteste connection (mit "mysqladmin processlist" ausgegeben) ist seit 8 Stunden im sleep mode.

Nur dieser Fehler wurde angezeigt, den habe ich aber behoben:
Code:
PHP Warning:  strftime(): It is not safe to rely on the system's timezone settings. You are *requi
red* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warni
ng, you most likely misspelled the timezone identifier. We selected 'Europe/Berlin' for 'CEST/2.0/DST' instead in /usr/share/phpmyadmin/libraries/common.lib.
php on line 1484,

EDIT:
Habe jetzt rausgefunden, dass diese Verbindungen vermutlich von diesen Dateien kommen:

Code:
/usr/local/ispconfig/server/server.sh
/usr/local/ispconfig/server/server.php

Davon sind knapp 2000 Prozesse offen bzw. im Status wait.
 
Zuletzt bearbeitet:

Till

Administrator
Schalte mal das debugging in ispconfig ein und poste dann die Ausgabe des Aufrufes von:

/usr/local/ispconfig/server/server.sh
 

Netscape

New Member
Debuggin ist angeschaltet und hier schon mal der inhalt der Dateien:

server.sh:
Code:
#!/bin/sh

PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin

. /etc/profile

/usr/bin/php -q /usr/local/ispconfig/server/server.php
server.php (den Teil den ich als fehlerquelle vermute):
Code:
// Check whether another instance of this script is already running
if(is_file($conf['temppath'].$conf['fs_div'].'.ispconfig_lock')){
  clearstatcache();
  for($i=0;$i<120;$i++){ // Wait max. 1200 sec, then retry
    if(is_file($conf['temppath'].$conf['fs_div'].'.ispconfig_lock')){
      exec("ps aux | grep '/usr/local/ispconfig/server/[s]erver.php' | wc -l", $check);
      if(intval($check[0]) > 1) { // 1 because this is 2nd instance!
          $app->log('There is already an instance of server.php running. Exiting.', LOGLEVEL_DEBUG);
          exit;
      }
      $app->log('There is already a lockfile set. Waiting another 10 seconds...', LOGLEVEL_DEBUG);
      sleep(10);
      clearstatcache();
    }
  }
}

Und hier noch die Info´s vom pstree command:
Code:
     ├─crond─┬─1929*[crond───sh───server.sh───php───sh─┬─grep]
     │       │                                         ├─ps]
     │       │                                         └─wc]
 
Zuletzt bearbeitet:

Till

Administrator
Poste doch bitte mal die Ausgabe des Befehls und nicht den Quelltext der auf jeder ISPConfig Installation identisch ist. Das es nicht am Quelltext liegt kannst Du Dir ja sicher denken, da sonst niemand das Problem hat (bei um die 20 tausend Neuinstallationen pro Monat).
 

Netscape

New Member
Ich glaub auch nicht, dass es direkt am ISPConfig liegt.

Beim Aufruf des server.sh skripts passiert nichts und ich muss dass dann später (so ca. nach 10 min) mit STRG-C abbrechen.

Im Logfile /var/log/ispconfig/ispconfig.log steht leider gar nichts drin.
 

Till

Administrator
Du erhältst also garkeine Ausgabe? Dann überprüf bitte nochmal, ob für den Server wirklich der Loglevel "Debug" aktiviert ist. Dann editier den root-Crontab mit "crontab -e" und kommentier den Server.sh cronjob aus. Dann muss das ispconfig lockfile gelöscht werden mit:

rm -f /usr/local/ispconfig/server/temp/.ispconfig_lock

Den Befehl ggf. mehrfach ausführen, bis keine neue lockdatei mehr von wartenden serevr.php Prozessen angelegt wird. Als nächstes führst Du dann nochmal den Befehl:

/usr/local/ispconfig/server/server.sh

als root User aus. Es muss dann eine Ausgabe wie diese geben:

/usr/local/ispconfig/server/server.sh
20.09.2011-21:35 - DEBUG - Set Lock: /usr/local/ispconfig/server/temp/.ispconfig_lock
20.09.2011-21:35 - DEBUG - No Updated records found, starting only the core.
20.09.2011-21:35 - DEBUG - Loading Module: monitor_core_module

bzw. es müssen Fehler ausgegeben werden, wenn die Verarbeitung aus welchem Grunde auch immer nicht möglich ist.
 

Netscape

New Member
So, hab getestet was du vorgeschlagen hast.

Es schein unter anderem mit einem Eintrag in der root .bashrc zu liegen. Habe dort zwei aliase für das mounten eines ftp accounts mit curlftpfs angelegt. wenn ich diese aliase auskommentiere, läuft das skript sauber durch.

Code:
21.09.2011-15:53 - DEBUG - Set Lock: /usr/local/ispconfig/server/temp/.ispconfig_lock
21.09.2011-15:53 - DEBUG - No Updated records found, starting only the core.
21.09.2011-15:53 - DEBUG - Remove Lock: /usr/local/ispconfig/server/temp/.ispconfig_lock
finished.

Wenn ich die Einträge nicht auskommentiere, bleibt das skript hängen bzw. startet erst gar nicht.

Hier die Einträge der bashrc:
Code:
#alias mountftp="curlftpfs host.tld /mnt/ftp/ -o user=423423:3254234,allow_other"
#alias umountftp="fusermount -u /mnt/ftp"

Nun hat sich der Server auch noch aufgehängt, wegen out of memory was vom crond verursacht wurde.

Nun habe ich den Server mal neu gestartet und beobachte mal die connections und die ispconfig.log
 

Netscape

New Member
Also es scheint definitiv am curlftps zu liegen. Hab den Alias aus der .bashrc rausgenommen und das Backupscript ohne curlftps laufen lassen. Der Server lief 3 Tage ohne Probleme.

Dann hab ich das curlftps im Backupscript wieder eingebaut (ohne den Alias in der .bashrc) und der Server ist wieder abgeschmiert.

Kann mir jemand erklären, warum das so ist? Der Crond hat dann 2000 Prozesse am laufen und stürzt mit Out of Memory ab.

Würde mich interessieren, ob das noch jemand nachvollziehen kann.
 

Till

Administrator
Vermutlich läuft curlftps nicht bzw. bring den Prozess zum Absturz wenn er über cron aufgerufen wird. Da gibt es 2 Möglichkeiten. Entweder, Du nummst curlftps aus der bashrc raus oder aber Du erstellst eine Kopie der bashrc ohne curlftps und bindest Diese anstatt der normalen bashrc in das ispconfig server.sh script ein.
 

Netscape

New Member
Es liegt ja nicht nur an der bashrc. Da habe ich die Einträge rausgenommen und nur im Backupscript waren sie noch drin. Trotzdem schmierte der Server ab.

Also hat der Cronjob von ISPConfig auch ein Problem, wenn das backupscript mit curlftps über einen cronjob gestartet wird.
 

hahni

Active Member
Ich muss das Thema auch noch mal aufgreifen. Ich habe die max_connections und max_user_connections auf 1000 gesetzt - wie angeregt. Seitdem kommen die Fehler mit den Verbindungen nicht mehr. Dafür aber nun folgende, die auch noch eine abrupte Beendigung von postfix zur Folge haben:

--
Mar 25 04:42:41 server dovecot: auth-worker(20266): Error: sql(name@ndomain.de,x.x.x.x,<phc4+OKE8rNOhlpz>): Password query failed: Not connected to database
Mar 25 04:42:41 server dovecot: auth-worker(21081): Error: mysql(localhost): Connect failed to database (dbispconfig): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) - waiting for 1 seconds before retry
Mar 25 04:42:41 server dovecot: auth-worker(21081): Error: mysql(localhost): Connect failed to database (dbispconfig): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) - waiting for 1 seconds before retry
Mar 25 04:42:41 server dovecot: auth-worker(21081): Error: mysql(localhost): Connect failed to database (dbispconfig): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) - waiting for 5 seconds before retry
Mar 25 04:42:41 server dovecot: auth-worker(21081): Error: mysql(localhost): Connect failed to database (dbispconfig): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) - waiting for 5 seconds before retry
Mar 25 04:42:45 server dovecot: auth-worker(21081): Error: mysql(localhost): Connect failed to database (dbispconfig): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) - waiting for 25 seconds before retry
Mar 25 04:42:45 server dovecot: auth-worker(21081): Error: mysql(localhost): Connect failed to database (dbispconfig): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) - waiting for 25 seconds before retry
Mar 25 04:42:48 server postfix/postfix-script[21396]: fatal: the Postfix mail system is not running
Mar 25 04:43:10 server dovecot: auth-worker(21081): Error: mysql(localhost): Connect failed to database (dbispconfig): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) - waiting for 125 seconds before retry
Mar 25 04:43:10 server dovecot: auth-worker(21081): Error: mysql(localhost): Connect failed to database (dbispconfig): Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) - waiting for 125 seconds before retry
Mar 25 04:43:39 server dovecot: auth: Error: auth worker: Aborted PASSV request for web69_info: Lookup timed out
Mar 25 04:43:39 server dovecot: auth-worker(21081): Error: sql(user,x.x.x.x,<WkW3++KEGepP3f/S>): Password query failed: Not connected to database
Mar 25 04:43:39 server dovecot: auth: Error: Aborting auth request that was queued for 114 secs, 14 left in queue
Mar 25 04:43:39 server dovecot: auth: Error: Aborting auth request that was queued for 114 secs, 13 left in queue
Mar 25 04:43:39 server dovecot: auth: Error: Aborting auth request that was queued for 114 secs, 12 left in queue
Mar 25 04:43:39 server dovecot: auth: Error: Aborting auth request that was queued for 112 secs, 11 left in queue
Mar 25 04:43:39 server dovecot: auth: Error: Aborting auth request that was queued for 84 secs, 10 left in queue
Mar 25 04:43:39 server dovecot: auth: Error: Aborting auth request that was queued for 72 secs, 9 left in queue
Mar 25 04:43:39 server dovecot: auth: Error: Aborting auth request that was queued for 70 secs, 8 left in queue
Mar 25 04:43:39 server dovecot: auth: Error: Aborting auth request that was queued for 62 secs, 7 left in queue
--

Wie könnte ich denn dieses Problem beheben?
 

Werbung

Top