Linuxspicker

"Cannot fork" oder "can't fork" bei VPS-Systemen mit OpenVZ

7. Dezember 2023

Bei meinem virtuellen Server (VPS) von Strato fingen vor mehreren Jahren massiv Fehlermeldungen bei Cronjobs a la /bin/sh: 1: Cannot fork bzw. can't fork an, die auf hohe Load Averages von mehr als 100 zurückgingen und komplette Aussetzer nach sich zogen, die teils nur mit Neustarts zu beheben waren.

Wann genau diese Form von high loads und kompletten Blockaden einsetzten, ist nicht mehr nachvollziehbar. Vermutlich war es in der Zeit, als die Serversysteme von mechanischen Festplatten auf SSDs umgestellt wurden. In jedem Fall war es nervig und die Kommunikation mit dem Kundendienst brachte auch keine Lösung. Auch der Umstieg auf ein höherwertiges VPS brachte keine Abhilfe. 16 Kerne und 60 GB RAM wurden trotz geringer CPU-Last immer wieder komplett ausgeknockt.

Bei regelmäßigen Aussetzern ließen sich nach einiger Zeit mehrere Cronjobs als Verursacher identifizieren. Das waren vor allem Backups der Datenbanken und von Mails mit großen Archiven. Dabei wurde der Dateisystemcache (siehe free) intensiv genutzt, aber anschließend aus irgendeinem Grund nicht freigegeben, was zu Speichermangel und einer entsprechenden Blockade des Systems führte. Die Cronjobs mit /bin/sync zum Schreiben des Caches auf die Festplatte zu animieren, brachte keine Erleichterung. Auch die im Netz kursierenden Empfehlungen zum Pagecache auf Einzelsystemen mit dem Befehl /sbin/sysctl -w vm.drop_caches=3 sind bei einem VPS wirkungslos und brachten keine Erleichterung.

Die Lösung für diese Aussetzer war es, einfach den Backupprozessen die Nutzung des Dateisystemcaches auszutreiben. Dafür gibt es auf Linuxsystemen das Programm nocache. Das lässt sich mittels apt install nocache auf Debian-Systemen nachinstallieren. Also wird tar in /bin/tar -cjf ... dann ein /usr/bin/nocache vorangestellt und damit die Cachenutzung zumindest minimiert.

Das Backup aller Verzeichnisse in /var/www in einzelne Archive mittels zstd und mit Datum im Namen sähe dann so aus:

cd /var/www

for dir in `find * -maxdepth 0 -type d`
do
  base=$(basename "$dir")
  datum=`date +\%d.\%m.\%Y-\%H\%M\%S`
   /usr/bin/nocache /bin/tar -cf "/backups/www/www-backups-${base}-$datum.tar.zst" -X <(find "$dir" -size +10M) --use-compress-program=/usr/bin/zstd --exclude=*.br --exclude=*.gz  --exclude-caches-under --exclude-backups "$dir"

done

In obigem Beispiel wurde gzip beziehungsweise bzip2 bereits durch das schnellere und effizientere zstd ersetzt.

Die auf Cronjobs zurückzuführenden Blockaden ließen sich somit per Voranstellen von /usr/bin/nocache beheben. Eine weitere Linderung brachte der Einsatz von zstd unter anderem bei Logrotate, wodurch die Kompressionszeit massiv verkürzt wurde. Allerdings gab es weiter unregelmäßige Aussetzer, die einen anderen Verursacher haben.

Hinweise des Supports die /proc/user_beancounters zu überwachen, brachten einen auch nicht weiter. Alle Systemrestriktionen wurden eingehalten. Der Verdacht, dass fail2ban wegen numiptent an seine Grenzen stößt und dadurch das System blockiert wird, konnte auch nicht erhärtet werden.

Als dieser hat sich die laufende Mariadb-Instanz herausgestellt. Das konnte aber nur durch eine Reihe von trial and error-Versuchen herausgefunden werden. In dem Fall wurde Mariadb einfach mit den Standardeinstellungen laufen gelassen und siehe da die krassen high load bedingten Aussetzer verschwanden wie von Zauberhand. Die Einstellungen von Mariadb waren dabei mit MysqlTuner optimiert worden, wobei sich drei speicherintensive Einstellungen als Verursacher identifizieren ließen.

join_buffer_size (> 24.0M, or always use indexes with JOINs)
tmp_table_size (> 24M)
max_heap_table_size (> 24M)

Alle drei Werte waren auf 64 MB und mehr gemäß den Empfehlungen von MysqlTuner eingestellt. Das war auch durch den vorhandenen Speicher von 60GB gerechtfertigt, allerdings war das wie oben geschildert in der Praxis ein Trugschluss. Nach längeren Tests wurden alle drei Werte, wie oben ersichtlich, auf 24 MB reduziert und seitdem läuft das System stabil ohne Aussetzer.

Die Schlussfolgerung ist, dass OpenVZ-basierte VPS-Systeme nicht wirklich für intensivere Datei- und Datenbankoperationen geeignet sind. Vermutlich hat Strato deswegen jetzt auch die Umstellung von OpenVZ auf KVM vollzogen. Abhilfe schaffen aber nocache und eine Anpassung der Parameter der Datenbankanwendung.

Stichworte: Cache, High load, Load average, Mariadb, Mysqltuner, Nocache, Openvz, Server, Strato, Virtual private server
Kategorien: Linux