Produktive Linux VM läuft 50/50

[ohxblivion]

Ich hoffe das ich hier jemanden finde der vielleicht ähnliche Probleme hatte damit.

Ich betreibe ein 2 Node Cluster mit einem Q-Device (als vollwertigen Server aber ohne Storage-Anbindung, also nur als Entscheidungsgeber). Nun habe ich auf einem Knoten eine Linux VM laufen die für die Arbeit in unserer IT-Abteilung wichtig ist. Das Problem hierbei ist, dass die Browserseiten manchmal extrem schnell laden und im nächsten Moment ca. 1-2 Minuten brauchen um sich aufzubauen.
Ich weiß nicht ob ich in der Konfiguration irgendwas falsch gemacht habe oder was da die gängige Praxis ist (siehe Bilder), aber die Performance ist halt eben nicht so geil.

Hab bevor ich die VM migriert habe alles an Anforderungen bei VMware abgecheckt, die VM funktioniert auch ohne Schwierigkeiten. Auch die Qemu Gasttreiber habe ich installiert.





Die beiden Nodes sind mit dem NFS-Storage angebunden.

Für jede Hilfe bin ich sehr dankbar!

 

[aaron]

2 sockets mit 3 cores ist ein wenig seltsam. Ist der Server ein Multisocket System? Falls nicht, die Sockets lieber mal auf 1 und die Cores auf 6 geben.

Was für eine HW hat der Server selbst? CPU cores/threads? Wie schnell ist die Anbindung an den NFS share?

Sieht du im CPU/IOwait Graph auf der Node->Summary, dass IO Wait zu den Zeitpunkten, an denen es Probleme gibt, in die Höhe geht? Das wäre ein Indikator dass das Storage evtl. zu langsam ist.

 

[ohxblivion]

Das mit den Kernen stelle ich mal um bzw. hab ich laut Recherche gelesen das es klug wäre die CPU auf Host zu stellen.

Als Hardware hab ich einen Supermicro SMXSH Server mit einer Intel CPU. Meine Server sind per Glasfaser mit 10Gbit/s angebunden, was es nicht unbedingt langsam machen sollte. CPU ist ein Intel Xeon Gold 5315Y dritter Generation mit 8 Kernen und 3,2 GHz.

Das einzige was ich gesehen habe das es in die Höhe geschossen ist war als das kurz abgekracht ist. Ansonsten ist es relativ ruhig

 

[ohxblivion]

habs jetzt mal geändert, nur minimal besser geworden.



und so siehts erstmal aus mit der Disk IO.
CPU-Auslastung bewegt sich zwischen 0.15 und 0.20 %.

 

[aaron]

Ein 5315Y hat 8 Kerne / 16 Threads. Das ist jetzt nicht so viel, je nachdem was alles auf dem Host läuft.

Kann das Problem auch am Quorum Device liegen?

Nein. Das hat auf die Performance einer VM keinen Einfluss.

und so siehts erstmal aus mit der Disk IO.

Ich meinte den IO Wait, welcher der zweite Graph im CPU Load Graph ist. Dieser ist ein Indikator, wie lange Prozesse darauf warten, dass IO fertig wird.

Da die CPU auch recht klein ist, kannst du auch mal Regelmäßig die CPU Pressurewerte mit cat /proc/pressure/cpu abfragen.

$ cat /proc/pressure/cpu
some avg10=0.00 avg60=0.00 avg300=0.00 total=124609016
full avg10=0.00 avg60=0.00 avg300=0.00 total=0

Wenn in der Some Zeile für die letzten 10, 60 & 300 Sekunden der Wert höher als 0 ist, mussten Prozesse auf CPU Zeit warten. Was ein Indikator ist, dass die CPU überprovisioniert ist. Da kann es dann helfen, den VMs weniger CPU Kerne zu geben, dann tut sicher Scheduler leichter, den VMs CPU Zeit zu geben.

 

[ohxblivion]

Guten Morgen, ich hatte das Problem tatsächlich gestern noch gefunden, deswegen kam bis jetzt keine Antwort.

Ich habe ja einen Netzwerkspeicher bei beiden Servern dran und eigentlich für jede NetApp Schnittstelle eine gesonderte IP angegeben, aber anscheinend bei dem zweiten Node nicht. Deswegen kam sich das total in die Quere

Trotzdem danke für die Hilfe und die Infos nehme ich auf jeden Fall mit !

 

[aaron]

Ich habe ja einen Netzwerkspeicher bei beiden Servern dran und eigentlich für jede NetApp Schnittstelle eine gesonderte IP angegeben, aber anscheinend bei dem zweiten Node nicht. Deswegen kam sich das total in die Quere

Wurde der Traffic zum NFS dann via Router ins richtige Netz geschickt anstatt dass der Host direkt mit dem NFS share redet? Damit ich das auch verstehe

 

[ohxblivion]

Wurde der Traffic zum NFS dann via Router ins richtige Netz geschickt anstatt dass der Host direkt mit dem NFS share redet? Damit ich das auch verstehe

Also wenn jetzt, wie in meinem Fall der Testserver den ich vorher hatte und der jetzige Server, ein und diesselbe Adresse für die Netzwerkanbindung zum NFS-Share haben, kommen sich beide in der Benutzung in Konflikt, was dazu führt das der Storage immer wieder aussteigt aus dem Server. Ist sowieso da ne ungute Idee wenn beide sich eine Leitung teilen müssen
Auf jeden Fall wenn du NFS-Share benutzen solltest und zwei Server hast, dann immer eine andere Adresse dafür benutzen

Das ist die Config für meinen NFS-Share auf Node 1


Und das ist die Config für den NFS-Share auf Node 2. Das einzige was eben gleich bleibt ist der Gateway, aber die unterschiedlichen IP-Adressen damit die sich eben nicht in die Quere kommen und Störungen verursachen. An sich wurde der Traffic genau so rausgeschickt. Bloß eben das dann zwei gleiche Pakete raus gegangen sind, die ein und diesselbe Angabe hatten. Ist dann logisch das es nicht gut geht.

 

[aaron]

Also wenn jetzt, wie in meinem Fall der Testserver den ich vorher hatte und der jetzige Server, ein und diesselbe Adresse für die Netzwerkanbindung zum NFS-Share haben, kommen sich beide in der Benutzung in Konflikt,

Aaah, jup duplicate IP Probleme sind meh...