Der Server
2a02:180:6:1::1458
liegt derzeit auf einem Hostsystem, was davon nicht betroffen war.
Mein VS2-free war am 16.6.2020 von 9:26 Uhr bis 9:55 Uhr nicht erreichbar. Ich überwache alle meine virtuellen Server per UptimeRobot, so auch den VS2-free mit der IP 2a02:180:6:1::1458. Ich konnte mich zu dieser Zeit nicht an dem System anmelden. Nach dieser Zeit, als ich mich wieder einloggen konnte, war die Uptime bei 0 und vorher laufende Dienste liefen nicht mehr. Es kann also nicht sein, dass nur das Netzwerk während dieser Zeit nicht verfügbar war.
Ohne gestarteten Docker Dienst (mit lokalen Diensten: NGINX, OpenVPN, Wireguard Go, Plik):
lsof | wc -l
1402
mit gestartetem Docker Dienst, aber ohne laufende Docker Container (das funktioniert ja leider nicht mehr):
lsof | wc -l
1946
Diese Aussage stimmt leider nach etwas Recherche, wie weiter unten beschrieben, nicht:
Too many open files
ist ein Problem im vServer, nicht des Hostsystems (=unbegrenzt).
Limits, die ich selbst setzen kann, sehen ok aus:
ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 128418
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 4096
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) unlimited
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimitedDies sind Host Werte und können von Benutzern nicht geändert werden:
sysctl fs.inotify
fs.inotify.max_queued_events = 16384
fs.inotify.max_user_instances = 1024
fs.inotify.max_user_watches = 8192Eigentlich sollte
fs.inotify.max_user_instances = 1024für 100 LXC Container/VServer reichen. Ich weiss natürlich nicht, wie viele LXC Container/VServer ihr pro Host laufen lasst. Ich hoffe nicht mehr als 60, was bei der Hardware des Servers (Xeon E3-1270 v3 / Quad Core mit HT / max 32 GByte RAM) schon z.B. für den RAM den doppelten Verbrauch bedeuten würde, den der Server eigentlich physisch zur Verfügung stehen hat. Ich verstehe, dass es ganz normal ist, dies zu tun, da wahrscheinlich nur ein Bruchteil der LXC Container/VServer den kompletten zugewiesenen RAM benutzt.
Es handelt sich scheinbar um ein Problem mit SystemD und LXC und dem
inotify instances upper limit
welches schon bei überschaubaren Mengen von LXC VServern/Containern pro Host auftritt:
https://kdecherf.com/blog/2015/09/12/systemd-and-the-fd-exhaustion/https://unix.stackexchange.com/questions/465196/lxc-systemd-fails-after-the-19th-containerDieses Problem betrifft übrigens nicht nur Docker, sondern auch andere Dienste, die inotify benutzen.
Wireguard-go ist z.B. so ein Dienst, der sich nicht mehr starten lässt. Irgend jemand muss gestern kurzzeitig dafür gesorgt haben, das der Wert für knapp eine halbe Stunde wieder unter den Maximalwert gesunken ist, da ich gestern Abend wireguard-go wieder ohne Fehlermeldung starten konnte (Docker Container leider nicht).
Ich würde empfehlen, den Wert von
fs.inotify.max_user_instances = 1024
mal probeweise auf
fs.inotify.max_user_instances = 2048
zu ändern
Ich wäre dann auch sehr gerne dazu bereit, zu berichten, ob die Erhöhung dieses Wertes das Problem behoben hat.
Und was auch sehr schön wäre, ist, dass EUserv seine VS2-free Nutzer etwas mehr informiert über z.B. Serverkapazitäten, VServern per Node usw., dann würden vielleicht auch Diskusionen darüber, dass Docker Benutzer (wie ich) dafür verantwortlich gemacht werden, dass die Performance der VS2-free VServer so schlecht ist, was sicher eher an zu vielen VServern pro Node liegt.
Danke und mfg
mdoerges
Autor
Thema: Produkt-Updates 06/2020 für VS2/VS2-free Serverplattform (Gelesen 24552 mal)