Performance-Problem HP Proliant Microserver N40L

[Gelöschtes Mitglied 187979]

Hallo zusammen

Ich habe EXSi auf einem N40L mit 8GB Mem und 4x2TB HD inkl. 2. Lan-Karte am Laufen. Das ganze über GigaLan, ohne Raid-Hardware oder -Software, dient mir als Proxy/Gateway (Ubuntu Server ohne Schnickschnack), Fileserver und SMB-Domain-Controller. Leider ist die Performance grausam. Wenn ich 2GB von meinem PC auf den HP auflade, warte ich über 30min (Netzwerk- und HD- Monitoring ergeben zwischen 3000-6000kB/s!!!). Lade ich im gleichen Netz von PC zu PC, warte ich 20 sek, was meiner Erwartung entspricht. Mein Skill-Level: Vor 10 Jahre hätte ich sowas noch alleine hingekriegt ;-)

Danke für Eure Unterstützung!

DefC0n

 

[SystemX]

Wie ist die verbindung zwischen den Sachen PC zu PC = ? • PC zu HP = ?. SIeht für mich so aus als wäre der HP via 10/100M verbunden und die anderen Sachen via Gigabit-LAN.

Wie sieht die vernetzung aus ?.

 

[Gelöschtes Mitglied 187979]

Danke für Deine Antwort.

ESXi zeigt eine 1000er-Verbindung an (was nichts heissen muss).
Aber selbst mit 100mb würde es nur 3 min dauern.
Zudem verschiebe ich im Moment 4x2GB zwischen 2 DataStores (2 physische Platten) - also lokal - und nach 40 min ist der Vorgang immer noch nicht abgeschlossen. Die Fortschrittsanzeige ging ziemlich rassig auf ca. 80% und steht hier praktisch unverändert seit ca. 38 min. Die Restzeitanzeige verändert sich konstant nach oben und zeigt nun 4 min an (zunehmend).
Wäre das Problem beim Netzwerk, würde meines Erachtens bei einem Upload die HD-Led auch nicht auf Dauergrün stehen sondern sich eher langweilen.

Die Kiste ist mit einem Cat6a-Kabel per Gigabit-Switch (der gleich daneben steht), mit dem Intranet verbunden, an dem z.B. auch mein PC hängt.
Am 2. RJ45-Anschluss hängt noch ein anderes Lan, das sollte irrelevant sein, da sich meine Tests auf das o.g. Lan beziehen und auch die Mgmt-Konsole am ersten Lan hängt.

Die HDs laufen als AHCI, vielleicht ist der Controller überfordert. Prozessorlast ist bei ca. 15% (inkl. ein laufender Ubuntu Server, aber der frisst ja nichts).

---------- Post added at 16:10 ---------- Previous post was at 15:36 ----------

Hier noch der Netzwerk-Test mit NetIO:

TCP connection established ...
Receiving from client, packet size 1k ... 10.49 MByte/s
Sending to client, packet size 1k ... 31.68 MByte/s
Receiving from client, packet size 2k ... 13.01 MByte/s
Sending to client, packet size 2k ... 38.06 MByte/s
Receiving from client, packet size 4k ... 17.87 MByte/s
Sending to client, packet size 4k ... 49.20 MByte/s
Receiving from client, packet size 8k ... 20.70 MByte/s
Sending to client, packet size 8k ... 42.76 MByte/s
Receiving from client, packet size 16k ... 22.74 MByte/s
Sending to client, packet size 16k ... 58.27 MByte/s
Receiving from client, packet size 32k ... 23.53 MByte/s
Sending to client, packet size 32k ... 61.37 MByte/s
Done.

Obwohl mir die Werte nicht wirklich gefallen, zeigt das zumindest, dass das Netzwerk nicht der Flaschenhals ist (und zumindest 100mb abhandelt).

 

[Gelöschtes Mitglied 187979]

ATTO Disk Benchmark aus einer XP-VM ergab folgendes:



Das kommt zwar von einer VM, spiegelt jedoch die oberen Werte wieder.
Hab 4 WD AV-GP ( WD20EURS) verbaut.

 

[Steggi]

Diese Probleme mit den Schreibraten kenne ich sonst eigentlich nur von Controllern, die aus welchen Gründen auch immer, ihren Writecache abgeschaltet haben.

 

[Gelöschtes Mitglied 187979]

Volltreffer



Vielen Dank

 

[Gelöschtes Mitglied 187979]

Wenn einem hier schon so gut geholfen wird, möchte ich noch die Netzwerk-Performance anschauen (s. oben):

Dies ist der Output von NetIO von PC1 zu PC2:

Packet size 1k bytes: 106.00 MByte/s Tx, 109.37 MByte/s Rx.
Packet size 2k bytes: 109.24 MByte/s Tx, 109.23 MByte/s Rx.
Packet size 4k bytes: 109.17 MByte/s Tx, 111.43 MByte/s Rx.
Packet size 8k bytes: 110.97 MByte/s Tx, 111.10 MByte/s Rx.
Packet size 16k bytes: 110.04 MByte/s Tx, 110.82 MByte/s Rx.
Packet size 32k bytes: 110.59 MByte/s Tx, 111.18 MByte/s Rx.

Die Performance von PC1 resp. PC2 zu HP-Server ist im Beitrag weiter oben angezeigt und entspricht bei weitem nicht dem erwarteten Durchsatz.

Alle 3 Geräte sind am selben Switch angeschlossen.
- Hab die Kabel PC1 / HP getauscht, keine Änderung
- danach die Kabel und das Mgmt-Netzwerk von HP (onboard) / HP (PCI-Card) getauscht, immer noch alles beim alten.

Woran kann das liegen?

Ach so: den NetIO-Test hab ich von einer XP-VM gemacht, spielt aber keine Rolle, weil ich dieselbe Performance auch per Mngt-Network (direkt in ESXi) habe.

 

[Tzk]

Diese Probleme mit den Schreibraten kenne ich sonst eigentlich nur von Controllern, die aus welchen Gründen auch immer, ihren Writecache abgeschaltet haben.

Im Bios vom N40L ist der Writecache Standardmäßig deaktiviert, mit dem Hinweis das Datenverlust passieren kann wenn der Strom ausfällt.
Ich werde das bei mir auch mal Durchtesten und Feeback geben.

DANKE für den Hinweis

 

[Steggi]

Im Bios vom N40L ist der Writecache Standardmäßig deaktiviert, mit dem Hinweis das Datenverlust passieren kann wenn der Strom ausfällt.

Joa, generell ist das eigentlich immer so, dass die Controller den Cache abschalten, wenn es keine BBU gibt, oder diese nicht voll genug ist. Ich bin aber grade überfragt, obs für den Onboardcontroller auch ne BBU gibt.

Woran kann das liegen?

Schwer zu sagen. Ohne nen Switch haste noch nicht probiert oder? Hast du irgendwo (egal ob an den PCs oder am Server) schonmal an der MTU Größe rumgespielt?

 

[Gelöschtes Mitglied 187979]

BBU hat der ziemlich sicher nicht.

MTU ist überall auf standard: 1500. Glaube nicht, dass der MTU 80% Einbusse ausmachen kann.
Vielleicht gibts ja ein Netzwerk-Write-Cache, das man im Bios einschalten kann
Der Switch liefert den Durchsatz, s. PC1 -> PC2, die hängen alle am gleichen.
Wie kann ich das ohne Switch testen? Meinst Du mit einem Kreuzkabel?

 

[Janero]

gbit lan hat meines wissens auto mdi-x

 

[NTB]

d.h. Kreuzkabel brauchst du nicht. probier es einfach aus.
denk dran, IPs statisch zu setzen

Gesendet mit der Hardwareluxx App

 

[Steggi]

Glaube nicht, dass der MTU 80% Einbusse ausmachen kann.

Ich aber Wenn eines der Geräte (auch der Switch) probleme mit ner zu großen MTU haben, dann bricht dir die Leistung deutlich weg. Habe bei mir auch schon mal zwei Server gehabt, die bei 9000er Frames deutlich langsamer waren als bei 1500 obwohl die komplette Hardware mit Jumbo Frames umgehen konnte

Vielleicht gibts ja ein Netzwerk-Write-Cache, das man im Bios einschalten kann

Computer sagt nein

Wie kann ich das ohne Switch testen? Meinst Du mit einem Kreuzkabel?

Jep, wobei wie Janero schon schrieb, kannst du alle GBit Karten auch mit nem normalen Patchkabel verbinden, da die Karten selbstständig die Sende und Empfangleitungen erkennen

 

[Mrsonei6]

Ich habe genau das selbe Problem mit dem HP Micro N54L

ESX 5.1
2 Virt Maschienen (1: SophosUTM ehem Astaro/ 2: Home Server 2011)
3x Datastore kein Raid (1= Virt Maschienen 2=Daten Partition 3= Video Musik)

Meinen PC direkt mit dem Micro Server verbunden ohne Switch.
20 GB ala 7x Videos von PC zu Home Server kopieren 3M/s
Vom Server selbe daten auf PC kopieren geht mit 70 M/s

Da ich direkt verbunden bin muss es am ESX, Home Server oder am Micro Server liegen
Habe alle Netzwerkkarten Vollduplex Auto gelassen!


Was war bei dir die Lösung?
Im Bios des Micro Server den Cache einschalten?
hast du MTU irgendwo verändert?


LG
Ich

 

[d0ner]

Hatte auch Nas4Free und Freenas unter ESXi am laufen und genau wie ihr eine miese Schreib-Performance gehabt. Das kommt durch die virtualisierten Festplatten. Es gibt Wege die über RDM auch physisch in die VM einzubinden( RDM mapping of local SATA storage for ESXi « David Warburton ), aber das hat bei mir nicht geklappt. Die waren immer 0 MB groß. Windows hat sie gefunden...

Warum man auch unter RaidZ1 nur 3/5/etc Platten nehmen sollte, erklärt Wikipedia am Raid 5 Beispiel ganz gut:

Einfluss auf die Write-Performance

Im Unterschied zur Read-Performance ist das Ermitteln der Write-Performance bei RAID 5 deutlich komplizierter und hängt sowohl von der zu schreibenden Datenmenge, als auch von der Anzahl der Platten ab.[2] Ausgehend von Festplatten mit weniger als 2TB Plattenplatz, ist die atomare Blockgröße (auch Sektorgröße genannt) der Platten häufig 512 Byte (siehe Festplatte: Speichern und Lesen von Daten). Geht man weiter von einem RAID-5-Verbund mit 5 Platten (4/5 Daten und 1/5 Parität) aus, so ergibt sich folgendes Szenario: Will eine Anwendung 2048 Byte schreiben, wird in diesem günstigen Fall auf alle 5 Platten genau je ein Block zu 512 Byte geschrieben, wobei einer dieser Blöcke keine Nutzdaten enthält. Im Vergleich zu RAID 0 mit 5 Platten ergibt sich daraus eine Effizienz von 80 % (bei RAID 5 mit 3 Platten wären es 66 %). Möchte eine Anwendung nur einen Block von 512 Byte schreiben, so ergibt sich ein ungünstigerer Fall, es müssen zuerst der abzuändernde Block und der Paritätsblock eingelesen werden, danach wird der neue Paritätsblock berechnet und erst dann können beide 512-Byte-Blöcke geschrieben werden. Das bedeutet einen Aufwand von 2 Lesezugriffen und 2 Schreibzugriffen, um einen Block zu speichern. Geht man vereinfacht davon aus, dass Lesen und Schreiben gleich lange dauern, so beträgt die Effizienz in diesem ungünstigsten Fall, dem sogenannten RAID 5 write Penalty, noch 25 %. In der Praxis wird dieser Worst-Case-Fall bei einem RAID 5 mit 5 Platten aber kaum eintreten, denn Dateisysteme haben häufig Blockgrößen von 2 kB, 4 kB und mehr und zeigen daher praktisch ausschließlich das Well-Case-Schreibverhalten. Gleiches gilt analog für RAID 5 mit 3 Platten. Unterschiedlich verhält sich hingegen etwa ein RAID-5-System mit 4 Platten (3/4 Daten und 1/4 Parität), soll hier ein Block von 2048 Byte geschrieben werden, sind zwei Schreibvorgänge notwendig, es werden dann einmal 1536 Byte mit Well-Case-Performance geschrieben und noch einmal 512 Byte mit Worst-Case-Verhalten. Diesem Worst-Case-Verhalten wirken zwar Cache-Strategien entgegen, aber dennoch ergibt sich hieraus, dass bei RAID 5 möglichst ein Verhältnis von zwei, vier oder auch acht Platten für Nutzdaten plus einer Platte für Paritätsdaten eingehalten werden sollte. Daher haben RAID-5-Systeme mit 3, 5 oder 9 Platten ein besonders günstiges Performanceverhalten.

 

[Mrsonei6]

Hallo d0ner

ich hab gegenwertig noch kein tuning problem sondern wie der Thred ersteller ein echtes Performance Problem
3M/s ist echt langsam

Ist das einzige was der Thred ersteller gemacht hat den Chache im BIOS einzuschalten?

Oderr wurde sonst noch etwas verändert?

 

[Gelöschtes Mitglied 187979]

Hab jetzt das Kabel mal direkt angeschlossen, bringt keine Veränderung:

TCP connection established ...
Receiving from client, packet size 1k ... 9171.41 KByte/s
Sending to client, packet size 1k ... 34.99 MByte/s
Receiving from client, packet size 2k ... 11.20 MByte/s
Sending to client, packet size 2k ... 50.81 MByte/s
Receiving from client, packet size 4k ... 16.25 MByte/s
Sending to client, packet size 4k ... 60.51 MByte/s
Receiving from client, packet size 8k ... 17.84 MByte/s
Sending to client, packet size 8k ... 56.41 MByte/s
Receiving from client, packet size 16k ... 20.45 MByte/s
Sending to client, packet size 16k ... 61.31 MByte/s
Receiving from client, packet size 32k ... 20.19 MByte/s
Sending to client, packet size 32k ... 65.10 MByte/s
Done.

Das Kabel ist ok, da lief vor einer Minute noch volle Kapazität drüber von meinem PC1.

Kurios finde ich den grossen Unterschied zwischen senden und empfangen. Die Empfangsleistung könnte man ja noch schlucken, aber senden bei 10-20% der möglichen Leistung ist schon schwach. Wieso diese grosse Differenz?


Ich spiele jetzt noch etwas mit den MTU-Werten, mal sehen, ob's hilft.

---------- Post added at 22:49 ---------- Previous post was at 20:04 ----------

Nö, das mit den MTU-Werten hat nichts gebracht. Auf ESXi konnte ich den Wert auch nur auf 1280 runter korrigieren, alles darunter hat's mir autokorrigiert.
War aber einen Versuch wert.

Hingegen hab ich im oberen Post die Seiten verwechselt. Upload an HP ist langsam, nicht Download.
Damit sieht die Welt für mich wieder etwas besser aus.
Wär aber schon interessant zu wissen, woher das kommt...

 

[TiCar]

Habt ihr mal geschaut ob irgendwo das IPv6 Protokoll an ist?

Hatte gestern den Fall auf einem frisch installieren PC mit Win7 x64 auf einer SSD wo IPv4 und IPv6 sich die Adresse "versucht" haben per DHCP zu holen. Das ganze lief in einem IPv4 Netzwerk und der Admin wußte nicht mehr weiter dort. Alles lief megaschnell bis auf die Netzwerkübertragungen. Nach dem Abschalten von IPv6 fluppte auch das mal richtig.

Wieso der Rechner allerdings per IPv6 kommunizierte habe ich nicht rausgefunden, da IPv4 auch eine Adresse hatte und man nirgends einstellen konnte wie er kommunizieren soll. Hatte aber auch nicht die Zeit im fremden Netzwerk bisle zu testen, da ich nur per Fernwartung auf dem besagte PC drauf war.

 

[Gelöschtes Mitglied 187979]

Vielleicht hab ich das mit der MTU-Messung falsch gemacht.
Betrifft MTU nur den Sender oder auch den Empfänger (den Switch kann ich ja nicht einstellen...).
Wie gehe ich vor? ESXi auf 1280 stellen (niedriger geht nicht, autokorrektur). PC1 auch auf 1280 einstellen... reicht das?

 

[agor]

Hast du das Problem mittlerweile gelöst? Ich habe das selbe, allerdings nur bei UDP.
Außerdem scheint meine Festplattenperformance ziemlich mies zu sein, trotz RDM Mapping

Von meinem PC als NETIO Client

B:\netio132\bin>win32-i386.exe -u 192.168.2.3

NETIO - Network Throughput Benchmark, Version 1.32
(C) 1997-2012 Kai Uwe Rommel

UDP connection established.
Packet size 1k bytes: 52.33 KByte/s (99%) Tx, 67.88 MByte/s (0%) Rx.
Packet size 2k bytes: 10.18 MByte/s (0%) Tx, 92.05 MByte/s (0%) Rx.
Packet size 4k bytes: 20.13 MByte/s (1%) Tx, 98.17 MByte/s (0%) Rx.
Packet size 8k bytes: 36.15 MByte/s (0%) Tx, 84.23 MByte/s (0%) Rx.
Packet size 16k bytes: 44.31 MByte/s (0%) Tx, 101.54 MByte/s (0%) Rx.
Packet size 32k bytes: 61.63 MByte/s (0%) Tx, 88.14 MByte/s (0%) Rx.
Done.


B:\netio132\bin>win32-i386.exe -t 192.168.2.3

NETIO - Network Throughput Benchmark, Version 1.32
(C) 1997-2012 Kai Uwe Rommel

TCP connection established.
Packet size 1k bytes: 77.69 MByte/s Tx, 97.06 MByte/s Rx.
Packet size 2k bytes: 91.44 MByte/s Tx, 93.21 MByte/s Rx.
Packet size 4k bytes: 110.41 MByte/s Tx, 103.82 MByte/s Rx.
Packet size 8k bytes: 109.79 MByte/s Tx, 101.56 MByte/s Rx.
Packet size 16k bytes: 96.86 MByte/s Tx, 105.15 MByte/s Rx.
Packet size 32k bytes: 110.69 MByte/s Tx, 105.79 MByte/s Rx.
Done.

 

[Gelöschtes Mitglied 187979]

@agor

Nein, ist noch nicht gelöst. Da hast Du ja immerhin einen besseren Durchsatz als ich...

 

[agor]

Benutzt du denn auch das Onboard NIC?

 

[Gelöschtes Mitglied 187979]

Ja, plus eine zusätzliche Intel-Karte.

 

[bollerfant]

ATTO Disk Benchmark aus einer XP-VM ergab folgendes:

Anhang anzeigen 222834

Das kommt zwar von einer VM, spiegelt jedoch die oberen Werte wieder.
Hab 4 WD AV-GP ( WD20EURS) verbaut.

Hi,
ich habe genau die selben Probleme mit meinem N40L. Windows 2008 R2 komplett frisch installiert. Kannst du mir genau sagen, was du gemacht hast?
Ich bekomms nicht hin, obwohl der Write Cache anscheinen aktiviert ist im BIOS ändert sich das Verhalten nicht

Ich hatte das BIOS mit der Anleitung hier geflasht und es hat auch alles funktioniert: HP ProLiant N40L MicroServer Build and BIOS Modification Revisited

Jemand eine Idee, was ich noch überprüfen könnte?

EDIT 1+2+3:
Ich habe folgendes herausgefunden:
Versuch #1: Beide Platten in dem RAID Menü (STRG+F) zu einem RAID1 zusammengefasst. In Windows zeigt der ATTO Bench katastrophale Werte.
Versuch #2: Beide Platten in dem RAID Menü wieder EINZELN gemacht. Dann in Windows Server 2008 R2 ein gespiegeltes Volume erstellt. ATTO Bench zeigt katastrophale Werte.
Versuch #3: Beide Platten in dem RAID Menü immer noch EINZELN . In Windows Server 2008 R2 das gespiegelte Volume gelöscht und beide Platten ganz normal EINZELN eingebunden. ATTO Bench zeigt GUTE Werte bei einer, bei der anderen nicht.?!?!
Versuch #4: Beide Platten in dem RAID Menü immer noch EINZELN . In Windows Server 2008 R2 das gespiegelte Volume gelöscht und beide Platten ganz normal EINZELN eingebunden. Jedoch beide mal rausgenommen und nochmal reingesteckt. ATTO Bench zeigt GUTE Werte bei BEIDEN.?!?!
Versuch #5: Beide Platten laufen bei meinem anderen PC perfekt...
Versuch #6: Gleiches Setup wie bei #2 wieder gemacht. ATTO Bench zeigt plötzlich GUTE Werte.?!?!

Jetzt jemand eine Idee? Ich bin kurz davor meinen N40L gegen ein 2bay Raid von QNAP / Synology zu tauschen
Bin jetzt total verwirrt und weiss nicht mehr weiter...Echt...ich hab keine Ahnung was zur Hölle da abgeht...

 

[bollerfant]

Hi,
wollte nur anmerken, dass ich bei meinem letzten Versuch heute Nacht #6 das Setup unverändert ist. Also nur runter- und hochgefahren. Jetzt sind wieder schlechte Werte (und mit schlecht meine ich Write unter 1mb/sek. Lesen gut 125mb/sek)...

 

[hollywoodolq]

Ich hab hier mit einem n40l 16gb ram und esxi 5.5 das gleiche Problem. Mit dem internen RAIDkontroller hab ich zw 5 und 20mb auf die HDD und um die 30 mb/s auf eine SSD schreibgeschwindigkeit. Jetzt hab ich mir einen Adaptec 8505 mit 128mb Cache geholt und nen RAID 1 erstellt darauf hab ich jetzt maximal 40mb/s was ja fast schon Festplattengeschwindigkeit ist sind 2 langsame Desktopfestplatten zum testen, um mein produktives System nicht zu überschreiben) trotzdem hab ich mir von einem Hardwarekontroller mehr erwartet
Das zeigt zumindest das es ein kontrollerprpblem ist, doch tritt das nur unter Linux auf, ein testweise installiertes win 7 auf einer etwas älteren SSD brachte 160-190mb

Esxi scheint nicht optimal für den n40l zu sein. Hyperv scheint besser

 

[Janero]

mal das HP esxi image probiert?

 

[hollywoodolq]

ja das lässt sich garnicht installieren. kommt gleich ein fehler