Wieder ein spezielles Thema (sorry), aber sicherlich auch für andere Serverbetreiber mit ähnlichen Problemstellungen interessant.

Vorweg, „numothersock“ ist kein pfälzisches Äquivalent für die Aufforderung nach dem Griff eines bestimmten Kleidungsstücks – mitnichten.

Mein V-Server quengelte heute deshalb ein wenig herum, nach ein paar spontanen Freezes stürzte mySQL ab, anschließend frohr der Server ein und war nicht mehr erreichbar – nach einer Uptime von 100 Tagen schon ein wenig seltsam. Ein Blick ins VZPP offenbarte mir einen roten Ressorcenverbrauch – hier war von numothersock die Rede – das Limit betrug 400 und wurde am heutigen Tage desöfteren überschritten.

Bei „numothersocks“ handelt es sich um eine Anzahl von Sockets, welche zur Interprozesskommunikation dienen und hierzu geöffnet werden. Programme und Dienste öffnen also einen oder mehrere dieser Sockets, um miteinander kommunizieren zu können. Auf einem V-Server steht allerdings nur eine recht limitierte Anzahl zur Verfügung – je nach Zahl der verwendeten Dienste (apache, postfix, dovecot, mysql, voice, etc.) kann es letztendlich ein wenig knapp werden.

Werden zuviele Sockets verwendet, „hängen“ einzelne Programme oder der ganze Server – in den Logfiles unter anderem durch Meldungen wie „cannot allocate memory...“ erkennbar.

Die Socket-Verwendung lässt sich auf dem Server mittels netstat -p nachprüfen bzw. netstat -p | wc -l zum Ermitteln der Anzahl. Mittels cat /proc/user_beancounters erhält man noch eine nette Statistik hierzu.

Nutzt man Postfix als MTA (Mail Transfer Agent), kann folgender Eintrag in /etc/postfix/main.cf helfen, die Zahl der verwendeten Sockets zu reduzieren:

default_process_limit = 10

Diese Zahl ist für einen privat genutzten Mailserver mehr als ausreichend. Der Default-Wert beläuft sich im übrigen auf 100 und ist damit eher für Mailserver ausgelegt, welche ein weit größeres Volumen abwickeln müssen.

Siehe hierzu auch den folgenden Auszug aus http://www.postfix.org/TUNING_README.html:

Tuning the number of Postfix processes
The default_process_limit configuration parameter gives direct control over how many daemon processes Postfix will run. As of Postfix 2.0 the default limit is 100 SMTP client processes, 100 SMTP server processes, and so on. This may overwhelm systems with little memory, as well as networks with low bandwidth.

You can change the global process limit by specifying a non-default default_process_limit in the main.cf file. For example, to run up to 10 SMTP client processes, 10 SMTP server processes, and so on:

/etc/postfix/main.cf:
default_process_limit = 10

You need to execute „postfix reload“ to make the change effective. This limit is enforced by the Postfix master(8) daemon which does not automatically read main.cf when it changes.

You can override the process limit for specific Postfix daemons by editing the master.cf file. For example, if you do not wish to receive 100 SMTP messages at the same time, but do not want to change the process limits for other Postfix daemons, you could specify:

/etc/postfix/master.cf:
# ====================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ====================================================================
. . .
smtp inet n - - - 10 smtpd