VPS/vServer - virtual private server > VS2-free

Produkt-Updates 06/2020 für VS2/VS2-free Serverplattform

<< < (2/4) > >>

Forum-Support2:

--- Zitat von: mdoerges am 18.Juni 2020, 21:57:29 ---kann es sein, dass seit dem Software-Update bestimmte Dinge in den Containern nicht mehr funktionieren?

--- Ende Zitat ---

Nein. Es ist die Art des Load-Balancings durch zusätzliche Software-Routinen verbessert worden. Die Technik an sich (Kernel, Rechte usw.) ist identisch. Wir hatten allerdings ein paar Hostsysteme, die im Rahmen der neuen Logik rebootet werden mußten.

Der Server

--- Zitat ---2a02:180:6:1::1458
--- Ende Zitat ---
liegt derzeit auf einem Hostsystem, was davon nicht betroffen war.


--- Zitat ---Too many open files
--- Ende Zitat ---
ist ein Problem im vServer, nicht des Hostsystems (=unbegrenzt).

Ein

--- Code: ---lsof | wc -l
--- Ende Code ---
sollte alle offenen Dateien zählen. Uns interessiert, ab wann welcher Dienst nicht mehr nutzbar ist. In Abhängigkeit von der Produkt-Roadmap können wir das dann erweitern.

Generell gilt: Sofern sich grundsätzliche Änderungen an der Plattform ergeben, die Einschränkungen oder Änderungen am Server selbst nach sich ziehen, werden wir das vorher ankündigen und auch im Rahmen des CBCI-Betatests veröffentlichen.

mdoerges:

--- Zitat ---Der Server

    2a02:180:6:1::1458

liegt derzeit auf einem Hostsystem, was davon nicht betroffen war.
--- Ende Zitat ---
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):

--- Zitat ---lsof | wc -l
1402
--- Ende Zitat ---
mit gestartetem Docker Dienst, aber ohne laufende Docker Container (das funktioniert ja leider nicht mehr):

--- Zitat ---lsof | wc -l
1946
--- Ende Zitat ---

Diese Aussage stimmt leider nach etwas Recherche, wie weiter unten beschrieben, nicht:

--- Zitat ---    Too many open files

ist ein Problem im vServer, nicht des Hostsystems (=unbegrenzt).
--- Ende Zitat ---

Limits, die ich selbst setzen kann, sehen ok aus:

--- Code: ---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) unlimited
--- Ende Code ---
Dies sind Host Werte und können von Benutzern nicht geändert werden:

--- Code: ---sysctl fs.inotify
fs.inotify.max_queued_events = 16384
fs.inotify.max_user_instances = 1024
fs.inotify.max_user_watches = 8192
--- Ende Code ---
Eigentlich sollte

--- Code: ---fs.inotify.max_user_instances = 1024
--- Ende Code ---
fü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
--- Zitat ---inotify instances upper limit
--- Ende Zitat ---
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-container
Dieses 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

--- Code: ---fs.inotify.max_user_instances = 1024

--- Ende Code ---
mal probeweise auf

--- Code: ---fs.inotify.max_user_instances = 2048

--- Ende Code ---
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

Forum-Support2:
Hallo mdoerges,

die Belegung von Systemen erfolgt dynamisch. Man kann nicht sagen, welche Anzahl von Servern auf Hosts liegt. Das ändert sich ständig und ist von verschiedenen Faktoren abhängig. Das Hostsystem ist nur ein Faktor davon.

Das von Ihnen beschriebene Problem ist bekannt. Danke daher für Ihre bisher Mitwirkung und Anregungen. Derzeit werden dazu Tests intern durchgeführt. Es ist geplant, dazu eine Änderung im Zuge des nächsten Upgrades des Gesamtsystems 08 oder 09/2020 einzuführen. Wir würden uns dann über Feedback freuen.

Bzgl. Uptime sind VS2free auf optimale Verteilung im gesamten System ausgelegt. Hierbei werden VS2free regelmäßig neu verteilt. Es ist daher wie auch bei anderen Anbietern wichtig, alle Dienste, die laufen müssen, in die richtigen Runlevel einzutragen.

Die regulären VS2-Server werden im Rahmen von Funktionsupgrades jedoch zusätzliche Funktionen nutzen können. Wir nutzen das bereits intern für unsere eigene Infrastruktur. Mehr dazu kann ich zu diesem Zeitpunkt nicht mitteilen.

timtekno:
fyi
Die Load Balance ist meiner Meinung nach etwas besser geworden.
Ich konnte meine vServer  an zwei verschiedenen Tagen nicht erreichen.
TimTek

summer76:
Einer meiner v2-free Server (2a02:0180:0006:0001:0000:0000:0000:0c25) ist nun seit ungefähr einer Woche praktisch nicht mehr benutzbar: Prozessorlast ohne gestartete Anwendungen bei 100% (obwohl top -i im Schnitt nur ca. 15-20% angibt; aber der grafische Lastindex in der Lubuntu Taskleiste ist ständig auf Anschlag). Die Oberfläche (per vnc) reagiert fast gar nicht mehr auf Eingaben. Die kostenpflichtige IPv4 da drauf ist praktisch nutzlos, weil der Server auch per ssh erst nach Minuten reagiert.

Bei einer anderen, identisch konfigurierten Maschine ist die Performance zwar seit dem auch etwas nach unten gegangen, diese bleibt aber mit Einschränkungen noch benutzbar.

Bitte heile machen! Danke.

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete