Serverperformance

Servus,

aus meiner Not mache ich mal einen Thread:

Dort hab ich das Script (und andere) hinterlegt mit dem man ein Einloggen simulieren kann. Es macht momentan drei Webabfragen an die Schulkonsole. Das skript kann man gleichzeitig auf X Rechnern abfeuern und mal schauen, was der Server so treibt und wie lange das dauert.

Ich habe mal ein paar Tests auf meinem VirtualBox-Testrechner gemacht und an den Stellschrauben CPU-Anzahl, CPU-Performanz (%) und Harddisk-Bandbreite gespielt und die Responsezeiten gemessen:

  • die einstellbare Bandbreite hat nahezu keinen Einfluss siehe Manual VBox
  • die CPU-Performanz hat den größten Einfluss
  • die CPU-Anzahl hat Einfluss in der Größenordnung der User, wenn man mehr User als CPUs hat, erst dann geht die Performanz runter

RAM: Das ist auch ganz schön cool. Wer zu wenig RAM hat, dem schmieren dann login-vorgänge ab (klar). Das besondere ist „wann“ das passiert.

  • Bei 2.5G + 2G swap crashen die Serverprozesse bei 80 von meinen benchmarks
  • Bei 8G + 2G swap crashen manche Prozesse bei 160 von meinen benchmarks

Einerseits würde ich sagen: kein Problem, loggen sich denn 160 SuS gleichzeitig ein? Andererseits besteht mein Benchmark nur aus drei https-Anfragen, ein Login-Prozess besteht aus mehr als das, dazu noch der Loginprozess auf den clients usw…

Ich suche weiter auf meinem Produktivsystem nach Optimierungsmöglichkeiten…

VG, Tobias

1 „Gefällt mir“

Hallo Tobias,

cooles Tool, super Arbeit!!!:smiley::+1:

Das dürfte bei so manch einem ein Problem sein… :wink:

Viele Grüße,
Jochen

Hi zusammen,

ich will auch noch schildern, warum ich die Perfomanz messe:

  • Mein v6.2 Server war ein Xeon X3440@2.53GHz (8 cores durch hyperthreading)
  • Mein v7 Serverhost ist ein Xeon E5420@2.5 GHz (4 cores), darauf wird die v7 virtualisiert mit KVM
  • Mein Assistenzserver ist ein i3-2120@ 3.30GHz (4 cores) darauf Cloud, Docker, OpnSense mit KVM (danke @maxEG)

Obwohl die CPUs auf den ersten Blick nicht sooo unterschiedlich sind, liegen(lagen) nämlich seltsamerweise Welten zwischen der gefühlten Brauchbarkeit der v7 und der v6.2.

Und was hab ich versucht zu optimieren:

  • Die v6.2 war selbst nicht virtualisiert, sondern auf dem bare metal ! Dennoch hat die v6.2 als virtualisierungshost für alles andere gedient (!)
  • Inzwischen hab ich auch der v7 eine SSD dem Host und der Partition „serverroot“ untergeschoben, das scheint es gefühlt besser, aber messbar nicht schneller zu machen, die Schulkonsole zu benutzen.
  • Die Festplattensituation ist in beiden Fällen ähnlich: HDDs als Raid, im v6.2-Fall als Softwareraid-5 mit 5 Platten, im v7 Fall als Hardwareraid 5 mit 3 Platten
  • Die v6 war mit 2Gbit, die v7 mit 1Gbit angebunden, jetzt sind beide bei 2GBit
  • Ich habe die Firewall auf den Assistenzserver umgesiedelt und lasse nur noch die v7 auf dem Server laufen und ihr alle cores gegeben (warum virtualisiere ich eigentlich, fragt mich ein virtueller jonny).
  • Ich hatte auf der v6.2 nie die spectre-patches installiert (-30%, oder so?)

Es scheint eben nach meinen Tests so zu sein, dass meine Hardware nicht für einen sinnvolle Response der v7-Schulkonsole ausreicht, vor allem, wenn sich mehrere Personen anmelden. Vielleicht sind die CPUs des Xeon E5420 doch so deutlich weniger performant, plus virtualisierung, plus spectre-patches, dass man eben mehr Wumms braucht.
Sicherlich lässt sich noch an sophomorix-aufrufen optimieren, aber wenn ich der einzige bin, der verkrüppelte Hardware hat, wird das unwahrscheinlich sein…

Last but noch least: seit heute läuft meine v6 nicht mehr, ich habe den virtualisierungshost einfach kopiert und werde bald/irgendwann mal die v7 auf meinem Xeon X3440 laufen lassen, dann hab ich noch besseren überblick und vergleich.

VG, Tobias

Wir haben hier „nur“ Intel(R) Xeon(R) CPU E5-2609 0 @ 2.40GHz zur Verfügung. Das ist also mit deiner E5420vergleichbar. Es würde mich auf auf nächste Zeit auf der lml 6.2 festnageln, wenn lml7 nicht mit dieser Hardware läuft.

Hi Frithjof,
das wollte ich damit grade nicht sagen. Erstens ist es ja nicht so, dass es nicht läuft. Und außerdem sind die ja nur auf den ersten Blick vergleichbar. Wenn ich mal die datasheets anschaue:

Es könnte an so etwas „Banalem“ wie VT-d Virtualisierungstechnik liegen. Es kann auch gut sein, dass die messbaren Unterschiede, die ich jetzt „messe“ bei dir gar nicht zum Tragen kommen, weil deine Hardware neuer ist.

Und wie gesagt: es kann auch noch irgendetwas Schuld sein, was ich nicht bedacht habe und bei keinem von euch auftritt (siehe Wikipedia:Auer’sche Phänomena)

VG, Tobias

Noch etwas auffälliges an meiner HArdware: der Xeon E5420 hat laut Intel immer 12MB L2 Cache gehabt.
Meiner zeigt aber bei /proc/cpuinfo nur 6MB L2 Cache an…

Ich würde jedenfalls meine v7 Entscheidung nicht davon abhängig machen, was bei mir nicht funktioniert.
Ich würde, und ich denke das kann jeder, der bereits virtualisiert hat, einfach die v7 mal zu installieren und laufen zu lassen. Evtl. in den Ferien mit abgeschalteter v6. Dann kann ja mal „nachfühlen“ wie schnell ein „sophomorix-user -i -v -u testuser“ ist…

VG, Tobias

Kennst du diese Seite?

https://cpu.userbenchmark.com/Compare/Intel-Xeon-E5-2690-v2-vs-Intel-Xeon-X3440/m13436vsm6655

cool. danke.

aber auch mit Vorsicht zu genießen:

wegen des 100% höheren Market shares alleine ist der hundertfache Preis schon gerechtfertigt , oder… https://www.xkcd.com/937/

VG, Tobias

Hallo Tobias,

wegen des 100% höheren Market shares alleine ist der hundertfache Preis
schon gerechtfertigt , oder… xkcd: TornadoGuard

… ja, aber wenn ich mir unten die Specs anschaue, dann sehe ich da
schon einen sehr großen zu erwartenden Performance Unterschied:

Der X3440 hat HyperThreading: der hat 4 virtuelle Kerne mehr. Da kann
man sagen: ja, der gaukelt dem Betriebsystem vor, dass jeder Kern zwei
wären: deswegen hat der nicht mehr Kerne: aber es werden dann
tatsächlich unterschiedliche Bereiche der Kerne gleichzeitig verwendet:
HyperThreading bringt wirklich Performance. Natürlich ist ein echter 8
Kerner noch schneller…

Der BUS ist sehr weit auseinander. Der E5420 arbeitet noch mit FSB und
der X3440 hat einen DMI: ganz andere Liga.

Dem E5420 fehlen mehrere Virtualisierungstechnologien und TurboBoost…
der X3440 kann auf 2,93 GHz hoch takten …

Alles in allem ist die X Linie wohl die der „richtigen“ Xeons und die E
Linie wohl die der günstigen Xeons.
Das wird noch unterstrichen davon, dass der E5420 im LGA711 Sockel sitzt
und der X3440 im LGA1156

Zieh mal die V7 auf den anderen Server und teste dort nochmal: ich bin
gespannt…

(einfacher wäre es natürlich, wenn du einfach die CPUs umbauen würdest
… aber du hast ja Intel: die haben einen eigenen Sockel für jede CPU
… so hab ich manchmal das Gefühl…).

LG

Holger

Hallo Fritjof,

das wollte ich damit grade nicht sagen. Erstens ist es ja nicht so, dass
es nicht läuft. Und außerdem sind die ja nur auf den ersten Blick
vergleichbar. Wenn ich mal die datasheets anschaue:

Es könnte an so etwas „Banalem“ wie VT-d Virtualisierungstechnik liegen.

ja.
Ist nicht banal sondern macht viel aus.

Es kann auch gut sein, dass die messbaren Unterschiede, die ich jetzt
„messe“ bei dir gar nicht zum Tragen kommen, weil deine Hardware neuer ist.

viel neuer.
Der E5420 hat meiner Meinung nach ein riesen Bottelneck was
Hauptspeicheranbindung an geht: das hat der E5 von Fritjof nicht und der
X3440 ebenfalls nicht.

Und wie gesagt: es kann auch noch irgendetwas Schuld sein, was ich nicht
bedacht habe und bei keinem von euch auftritt (siehe Wikipedia:Auer’sche
Phänomena)

ich glaub der E5420 sollte eigentlich nicht den Namen „Ferrari“ tragen
sondern eher „Fiat“

LG

Holger

Hallo Holger

Ich finde das nicht einfach zu vergleichen mit den Angaben verschiedener Größen (mit versch. Einheiten) ‚Bus Speed‘ (GT/s QPI, GT/s DMI) bzw. ‚Bustaktrate‘ (MHz).

Hier habe ich ein bisschen was dazu gefunden:

Gruß
Stefan

Hallo Stefan,

Der E5420 hat meiner Meinung nach ein riesen Bottelneck was
Hauptspeicheranbindung an geht: das hat der E5 von Fritjof nicht und der
X3440 ebenfalls nicht.

Ich finde das nicht einfach zu vergleichen mit den Angaben verschiedener
Größen (mit versch. Einheiten) ‚Bus Speed‘ (GT/s QPI, GT/s DMI) bzw.
‚Bustaktrate‘ (MHz).

doch, genau da haben wir das Problem.
Es geht nämlich gar nicht um den Bus Speed: es geht um die Anbindung des
Hauptspeichers.
In Post 9 deines Links wird genau darauf hingewiesen.

Hintergrund: 2003 hatte AMD bei seinen K8 Prozessoren den
Speichercontroller von der Northbridge in den Prozessor direkt verlegt.
Das gab den K8 Athlons gegen den Intel Prozessoren einen erheblichen
Vorteil beim Speichertransfer.
Intel hat sich fast 5 Jahre lang geziert, bevor sie das auch so gemacht
haben. Die haben erstmal QPI gemacht und meinten, das sei ja viel
schneller … ist es nicht : aber es war ein cooler Marketingnamen.
Und genau liegen diese beiden CPUs auseinander: der Speichercontroller
ist beim X3440 in der CPU und beim E5420 noch in der Northbridge.

Deswegen wirkt die Aufstellung der Busbandbreiten in Post 7 auch erstmal
sehr seltsam:
FSB@1600Mhz= 12.8GB/s
QPI@6.4GT/s= 25.6GB/s
DMI@ 2.5 GT/s= 1.25GB/s(effectively 1GB/s due to overhead)

weil DMI ja viel langsamer ist als die anderen beiden.
DMI war die Anbindung zwischen North und Southbridge. Seit der
Speichercontroller im Prozessor direkt war, ließ Intel auch die
Northbridge weg: es blieb der DMI übrig.
In der Southbridge steckten nun aber keine so Datenintensiven Geräte
mehr: also mußte der BUS auch nicht mehr so breit sein.

Fazit: der E5420 ist ein Prozessor alter Architektur (aus dem Jahr 2007
Harpertown) und der X3440 ist ein Prozessor neuerer Architektur (2009
Lynfield). Wenn man hier nur auf GHz und Anzahl der Kerne schaut, dann
geht man fehl.
Bei diesen beiden besonders, weil nicht nur neue Befehlssätze und
optimierte Architektur die beiden unterscheidet, sondern auch weil der
Speichercontroller beim einen in der Northbridge steckt und beim anderen
in der CPU selbst steckt.

… nimm den X3440

LG

Holger

2 „Gefällt mir“

Super Analyse Holger, danke.
Ich denke, das hilft auch anderen (@frithjof z.B.)

VG, Tobias

Ich hatte Tobias so verstanden, dass es ein RAM Problem sei: 8gb für 160 nutzer a drei http Anfragen. Da Tobias „crashen“ schrieb, ging ich von sterben durch Speichermangel aus. Das muss ja aber nicht so sein.
Ferner hatte ich ihn so verstanden, dass die schulkonsole den Speicher beim Anmelden belegt, nicht jedoch nach dem Anmelden.
Daher sollte letztlich der Ramausbau für die Tauglichkeit eines systems entscheidend sein.

Platz 1 in dem CPU-Ranking ist auch interessant…

Hallo Tobias,

Ich hatte Tobias so verstanden, dass es ein RAM Problem sei: 8gb für 160
nutzer a drei http Anfragen. Da Tobias „crashen“ schrieb, ging ich von
sterben durch Speichermangel aus. Das muss ja aber nicht so sein.
Ferner hatte ich ihn so verstanden, dass die schulkonsole den Speicher
beim Anmelden belegt, nicht jedoch nach dem Anmelden.
Daher sollte letztlich der Ramausbau für die Tauglichkeit eines systems
entscheidend sein.

schreib mir mal, was für RAM du im E5420 Server drin hast: ich hab hier
einigen RAM rumlieben.
Gerade DDR2 hab ich in Hülle und Fülle: da könnte ich dir was von geben.
DDR3 hab ich auch ein wenig da.

LG

Holger

Hallo Frithjof,

Ich gehe auch von STerben durch Speichermangel aus, mindestens in dem 160-er Test habe ich oom-kills in den logs gesehen, denke ich, kann ich aber nochmal testen.

Ich weiß nicht, ob „Anmelden“ oder „Nach dem Anmelden“ unterschiedliche Vorgänge sind. Im Hintergrund werden einfach ein paar sophomorix-Befehle gestartet, egal ob das der Anmeldevorgang ist, oder ein anderer Vogang in der Schulkonsole.

Eine sinnvolle Abschätzung der Anzahl der „gleichzeitig“ in der Schulkonsole tätigen Benutzer ist … mir nicht bekannt. Vllt. kann Rainer und Rüdiger mit 3000 Usern mal sagen, was sie maximal gleichzeitig erleben.

Ich habe selbst nicht wirklich ein RAM Problem. Ich habe (nach deiner Analyse), wenn überhaupt ein Problem mit der CPU-Geschwindigkeit bzw. RAM-Bus-Anbindung.

6x2 GB DDR2 FB-DIMM , denk mal ECC

wäre mein Speicher.
Ich bin aber grade dabei das System auf dem X3440 zu spielen und werde dann nach Umzug mal schauen, ob der X3440 wieder Zicken macht (weswegen er ja aus dem Spiel war) oder ob die lmn7 rund läuft.

VG, Tobias

Yeah, läuft! (vorerst, die Zicken machte die CPU sporadisch… mal sehn)
Ich hab drei Anläufe gebraucht um die 370GB große VM „serverdata“ am zeiteffizientesten von A nach B zu migrieren. Statt 16 oder 18 STunden hat es dann nur ca. 4 Stunden gedauert und weitere 1 Stunde um per md5sum zu überprüfen ob es richtig war…

Hi Holger,
du hast voll recht: ein einzelner Benchmark läuft auf dem (auf den ersten Blick ähnlich schnellen X3440 System dreimal so schnell wie auf dem E5420), hier die Resultate als Grafik, ich habe sogar eine zweite Achse machen müssen, weil das einfach zwei Welten an unterschieden sind.

grafik

Jetzt hab ich ein annehmbar schnelles v7-System. Juhu!
Danke für euer Mitdenken! Ohne das hätte ich wahrscheinlich ewig rumgepfriemelt.

VG, Tobias

Hallo Tobias,

Hi Holger,
du hast voll recht: ein einzelner Benchmark läuft auf dem (auf den
ersten Blick ähnlich schnellen X3440 System dreimal so schnell wie auf
dem E5420),

… eigentlich bin ich ja ein Hardware Mensch.
Das ganze Softwarezeug ist eigentlich nicht so meins …

hier die Resultate als Grafik, ich habe sogar eine zweite
Achse machen müssen, weil das einfach zwei Welten an unterschieden sind.

grafik

magst du die Grafik nochmal machen, aber für den X3440 und den E5420 die
gleiche Skala verwenden?
Dann würde es einem nicht so das Gehirn raus drehen beim „lesen“.
Ich sehe da eher Faktor 5-8 zwischen den beiden Systemen und nicht nur 3 …

LG

Holger

da hast du recht: FAktor 3 nur bei einem einzelnen Aufruf, danach mehr:
grafik