Hp Proliant 10Gbit + Procurve 6400cl Slow performance

[Verwijderd]

Beste Mensen,


Bij een van onze klanten hebben we te maken met serieuze performance issues. De opstelling is als volgt:

Storage1 - HP Proliant DL160 Stroage Server --> HP NC510C 10Gbit NIC
Storage2 - HP Proliant DL380 Storage Server --> HP NC510C 10Gbit NIC
Server1 - HP Proliant DL380 Citrix Xen server 5.0 --> HP NC510C 10Gbit NIC

Dit alles is aangesloten op een Procurve 6400CL backbone switch. Theoretisch zullen we dus een snelheid tussen de Storage servers moeten kunnen behalen van 1,2GB/sec. Ik ben me er van bewust dat dit in de praktijk bijna niet haalbaar is door de andere verschillende componenten waar we mee te maken hebben.

De 2 storage-servers zijn voorzien van CentOS 5. Hierop is ISCSI + NFS geconfigureerd!

Als ik een kopieerslag doe (met scp of cp) van Storage server 1 ---> Storage server 2 heb ik een maximale doorvoersnelheid van 50MB/sec. Tevens wanneer ik dit van server 2 --> Server 1 doe.

Als ik een kopieerslag doe van de Citrix Xen server naar een van de storage servers haal ik maximaal 40MB/sec!

Ik heb alle firmware van de NIC's, Switch etc geupdate naar de recente versie!

De verbinding van de server en storage server naar de switch is geregeld d.m.v. een CX4 kopper verbinding!

Iemand ervaring met een soort gelijke situatie? Of iemand een idee waar het aan kan liggen?


Alvast bedankt!

[jep]

Het klinkt misschien als een domme vraag, maar wat voor een storage gebruik je en is dat wel allemaal 10GB capable?

[Verwijderd]

jep schreef op vrijdag 17 oktober 2008 @ 14:55:
Het klinkt misschien als een domme vraag, maar wat voor een storage gebruik je en is dat wel allemaal 10GB capable?

Het zijn Storage Servers.. Dus HP Proliant DL servers met Sata HDD's. Storage 1 is een Raid 5 opstelling, en Server 2 is een Raid 10 opstelling!

[lammert]

De kopieerslag van de Citrix XenServer, doe je die rechtstreeks of vanuit een virtual machine op die XenServer? Dat kan namelijk ook wat performance schelen, hoewel 20% wel absurd veel is.

Daarnaast: wat voor RAID controller en disks heb je in die XenServer zitten? Lijkt me redelijk essentiele info.

[FatalError]

Op die HP NC510C zit een Netxen chipset. Ik heb daar tot nu toe alleen maar HEEL erg slechte ervaringen mee gehad, waaronder HELE trage verbindingen.
Ik zou maar eens gaan kijken naar een Intel of Chelsio kaart. Die doen het tenminste wel fatsoenlijk.

[Verwijderd]

lammert schreef op vrijdag 17 oktober 2008 @ 15:00:
De kopieerslag van de Citrix XenServer, doe je die rechtstreeks of vanuit een virtual machine op die XenServer? Dat kan namelijk ook wat performance schelen, hoewel 20% wel absurd veel is.

Daarnaast: wat voor RAID controller en disks heb je in die XenServer zitten? Lijkt me redelijk essentiele info.

Ik doe de kopieerslag vanaf de console van de XENserver zelf.. Dus niet vanaf een VM..

Ik weet zo niet welke controllers erin zitten.. Maar komop jongens, 50MB/sec is sowieso veel te laag!!!

[lammert]

50 MB/s... het kan sneller ja. BBWC (Battery Backed Write Cache) op je RAID controller is aanwezig + ingeschakeld?

[Verwijderd]

lammert schreef op vrijdag 17 oktober 2008 @ 15:06:
50 MB/s... het kan sneller ja. BBWC (Battery Backed Write Cache) op je RAID controller is aanwezig + ingeschakeld?

Daar heb ik zelf ook al aan gedacht, helaas kan ik nu niet controleren of deze is ingeschakeld doordat het een live-omgeving is.. Ik ga dit volgende week maandag avond controleren!

Als BBWC niet aanwezig is, of niet ingeschakeld is. Kan dit dan voor zo'n gigantische performance verlies zorgen?

[ajhaverkamp]

Verwijderd schreef op vrijdag 17 oktober 2008 @ 15:09:
[...]
Als BBWC niet aanwezig is, of niet ingeschakeld is. Kan dit dan voor zo'n gigantische performance verlies zorgen?

Lijkt mij zeer onwaarschijnlijk, de BBWC voegt een accu toe voor het bewaren van de cache data tijdens stroomuitval (heeft niks met perfomance te maken) en voegt wat extra geheugen toe (hangt van het type RAID controller af, 128 MB of zo). Als je bv 1 GB aan data gaat kopieren, is de invloed van de cache al redelijk verwaarloosbaar omdat de cache dan nooit alle data kan bevatten, is hoogstens een beetje buffer tussen disken en netwerk.

Is het niet mogelijk om te testen met bv een crosscable? Met de huidige generatie DL360G5 heb ik rare problemen met de netwerkkaart als daar veel data over verstuurd wordt tijdens de backup. Dan verliest de kaart echt de verbinding en komt die ook niet meer terug. Als er maar een 100 MB of zo over de kabel gaat is er niks aan de hand. Nieuwste firmwares, nieuwste PSP. Dus met netwerkproblemen ben je niet helemaal uniek. Echter zal dit een ander probleem zijn.

[Anton]

Verwijderd schreef op vrijdag 17 oktober 2008 @ 15:09:
[...]
Als BBWC niet aanwezig is, of niet ingeschakeld is. Kan dit dan voor zo'n gigantische performance verlies zorgen?

Ja, want dan gaan alle writes direct naar disk, zonder dat daar een cache van een raid-controller tussen zit. (Zonder BBWC heb je geen write cache op een Proliant).

Als je wilt controleren of de disk de vertragende factor is (ik vermoed ook van wel) dan zou je zowel op de storage-server als op een andere host een RAM-disk moeten maken, en van ram-disk naar ram-disk kopieren over het netwerk. Als dat (veel) sneller gaat, dan weet je waar je bottleneck zit.

[ Voor 48% gewijzigd door Anton op 17-10-2008 15:22 ]

[jvanhambelgium]

Probeer eens met een iperf / netcps test om te zien wat de LAN performance tussen de hosts is ?? Kwestie om dat uit te sluiten...

[lammert]

ajhaverkamp schreef op vrijdag 17 oktober 2008 @ 15:18:
Lijkt mij zeer onwaarschijnlijk, de BBWC voegt een accu toe voor het bewaren van de cache data tijdens stroomuitval (heeft niks met perfomance te maken) en voegt wat extra geheugen toe (hangt van het type RAID controller af, 128 MB of zo).

Dat heb je verkeerd, Anton legt het hierboven al goed uit. Zonder BBWC geen cache op je RAID-controller (in ieder geval bij Proliants niet). Is ook wel zo prettig omdat anders bij stroomuitval de gegevens uit de cache verloren gaan en je met corrupte filesystems kan komen te zitten.

[ajhaverkamp]

Anton schreef op vrijdag 17 oktober 2008 @ 15:19:
[...]
Ja, want dan gaan alle writes direct naar disk, zonder dat daar een cache van een raid-controller tussen zit. (Zonder BBWC heb je geen write cache op een Proliant).

DL380G5 heeft doorgaans een P400i controller die standaard voorzien is van 256 MB. RAID controller zonder cache heeft HP niet meer in hun servers zitten, voor zover ik weet.

[FatalError]

Ik wil toch graag even herhalen dat die netwerkcontroller echt niet lekker is. Probeer voor de grap eens Netio of Netcps en zie dat dat ding gewoon rampzalig slecht presteert.

[NoE]

Hoeveel disken heb je in elke opstelling? IOPS worden namelijk gegenereerd op basis van het aantal disken!

SATA levert zo'n 75 IOPS in tegen stelling tot 15K SAS 200 IOPS

En wat voor type data gaat het? 50mb/s kan netjes zijn als het heel veel kleine bestanden zijn! het gevolg van kleine bestanden is dat je tegen je IOPS limiet loopt in tegenstelling tot je bandbreedte!

[jep]

Ik zie ook niet in hoe je op een dergelijke storage doos veel meer mb/s kunt doen. Laat 't richting de gigabit lopen voor zo'n doos, maar veel meer zou ik niet verwachten. Het zijn niet echt high end storage dozen.

[Verwijderd]

NoE schreef op vrijdag 17 oktober 2008 @ 15:37:
Hoeveel disken heb je in elke opstelling? IOPS worden namelijk gegenereerd op basis van het aantal disken!

SATA levert zo'n 75 IOPS in tegen stelling tot 15K SAS 200 IOPS

En wat voor type data gaat het? 50mb/s kan netjes zijn als het heel veel kleine bestanden zijn! het gevolg van kleine bestanden is dat je tegen je IOPS limiet loopt in tegenstelling tot je bandbreedte!

Het gaat om een .iso bestand van 1gb... Dus niet om losse filetjes..

Ik ga vanavond een ramdisk aanmaken van 1GB op beide servers, en hier een kopieer actie tussen te doen.. Dan sluit ik de storage iig uit!

[Fiander]

Staan jumboframes in je netwerk aan ?

standaard netwerk doet per frame iets van 1400byte,
met jumbo frames kun je hier wel 8K van maken.

Behalve dat je netwerk minder overhead heeft, geeft het ook minder belasting omdat er minder paketjes gerouteerd hoeven te worden.

edit : zijn het eigenlijks nic's welke dedicated voor de storage gebruikt worden, of gaat er ook ander netwerk verkeer overheen ?

[ Voor 19% gewijzigd door Fiander op 17-10-2008 16:14 ]

[NoE]

Ok, als ik het goed begrijp knoop je dus op je NAS (storageserver) systeem 2 iscsi luns aan en doet een copy van LUN a naar LUN b.

Zoals eerder al genoemd kunnen jumbo frames en TOE NIC's aardig wat bijdragen om de efficientie omhoog te gooien.

Aan de andere kant kan een verkeerde storage config, ik neem aan dat er een MSA2000 ofzo iets dergelijks onderhangt. ik doel dan meer op, hoe is deze geconfigureerd? RAID5 RAID6? op de host weer gestriped? of 2 boxen in een mirror?

Daarnaast heb je nog met verschillende lagen te maken:
[disks] => [raid config] => [segmentsize] => [controller] => [tcp/ip port] => [iscsi] => [tcp/ip nic] => [OS & drivers] => [disk config] => [filesystem] => [share] => [netwerk filesystem]

en filesystems komen weer met blocksizes

edit:
Ik las er even overheen, het gaat over interne disken

4 voor de Dl160G5 en 8 stuks voor de DL380G5.

Wat haal je met benchmark programma's? IOMeter?

[ Voor 12% gewijzigd door NoE op 17-10-2008 16:48 ]

[MoBi]

Kun je ook eens de specs van de storage server posten? Dus hoeveel disken en wat voor capaciteit? Ik verwacht net zoals jep dat er niet meer performance uit te trekken is. Heb je al eens gemonitord op de storage servers wat de bottleneck daar is? Geheuegen, CPU, Disk, Netwerkkaart?

[Verwijderd]

Heren,


Ik heb vandaag een test gedaan wat de IO snelheid is van de disken.. Ik kom op server 1 op een snelheid van 289Mb/sec, en op server 2 een snelheid van 149Mb/sec.

De 50Mb/sec die ik haal bij een kopieerslag van server 1 naar server 2 ligt dus niet aan de storage..

[Question Mark]

Wat en hoe heb je precies gemeten. Is dit je Read of Write snelheid?

En post nu eens een keer de diskconfig van je servers (welke disken en hoeveel, en wat voor Raid level). Ik vind het sowieso vreemd dat je Raid 5 Lun een Raid 10 Lun outperformed.

ajhaverkamp schreef op vrijdag 17 oktober 2008 @ 15:25:
[...]

DL380G5 heeft doorgaans een P400i controller die standaard voorzien is van 256 MB. RAID controller zonder cache heeft HP niet meer in hun servers zitten, voor zover ik weet.

Kan wel zijn, maar zonder BBWC wordt deze enkel voor Read gebruikt. Ook als je het gebruik van write cache handmatig enabled (properties van je disk in Device manager) zal de driver van de Raid controller deze weer uitschakelen.

[ Voor 112% gewijzigd door Question Mark op 23-10-2008 14:16 ]

[axis]

jvanhambelgium schreef op vrijdag 17 oktober 2008 @ 15:23:
Probeer eens met een iperf / netcps test om te zien wat de LAN performance tussen de hosts is ?? Kwestie om dat uit te sluiten...

Dit lijkt me het meest zinnige, met iperf testen wat de maximale netwerk-throughput is. Lijkt me toch wel enigzins handig om te weten...

Verwijderd schreef op vrijdag 17 oktober 2008 @ 15:09:
[...]
Daar heb ik zelf ook al aan gedacht, helaas kan ik nu niet controleren of deze is ingeschakeld doordat het een live-omgeving is.. Ik ga dit volgende week maandag avond controleren!

Als BBWC niet aanwezig is, of niet ingeschakeld is. Kan dit dan voor zo'n gigantische performance verlies zorgen?

Ook al is het een productieomgeving, dan kun je toch nog remote inloggen op die hp insight dinges en controleren hoe de raid settings zijn? (Weet niet hoe het ding precies heet, heb hier alleen Dells)

[ Voor 44% gewijzigd door axis op 23-10-2008 15:53 ]

[FatalError]

Ik wil niet vervelend doen, maar draai echt n keer iperf/netio/netcps...
Die Netxen chip is RUK (voorzichtig uitgedrukt). Ik hoop dat dat met n fatsoenlijke driver ooit eens gefixt kan worden, maar ik heb er weinig vertrouwen in.

[ Voor 30% gewijzigd door FatalError op 23-10-2008 23:32 ]

[Verwijderd]

FatalError schreef op donderdag 23 oktober 2008 @ 23:27:
Ik wil niet vervelend doen, maar draai echt n keer iperf/netio/netcps...
Die Netxen chip is RUK (voorzichtig uitgedrukt). Ik hoop dat dat met n fatsoenlijke driver ooit eens gefixt kan worden, maar ik heb er weinig vertrouwen in.

Ik heb net de netwerksnelheid getest met netio. En ik haal effectief 270Mb/sec.

Dit is nog lang geen 10Gbit. Maar altijd een stuk meer als 50Mb/sec.

Ik heb met een linux scriptje getest hoesnel een kopieer actie gaat van geheugen naar HDD. Hier haal ik max. 280Mb/sec.

Ik snap nu helemaal niet meer waar deze lage performance door komt. IO snelheid van HDD's is voldoende, de Netwerksnelheid is ook redelijk.. Maar toch blijkt er iets fout te gaan!


Testresultaten:


TCP connection established.
Packet size 1k bytes: 300453 KByte/s Tx, 255950 KByte/s Rx.
Packet size 2k bytes: 322682 KByte/s Tx, 254605 KByte/s Rx.
Packet size 4k bytes: 326957 KByte/s Tx, 253424 KByte/s Rx.

[ Voor 13% gewijzigd door Verwijderd op 24-10-2008 11:34 ]

[jvanhambelgium]

OK, de LAN ziet er behoorlijk uit.
Ik las dat je beide storage servers als iSCSI target en NFS server heb geconfigged.

Tijdens het copieren van de files, wat dit met NFS of heb je file access via iSCSI gedaan ??
Welke soort file-systems leven er op de verschillende systemen ?

"out-of-the-box" NFS is er al héél wat jaartjes oud en heeft echt wel tuning nodig op "hedendaagse" gigabit & 10 gig links !! NFS werd ontwikkelde in het 10megabits/s ethernet tijdperk.
De NFS-schaling van 100BaseT->Gige gaf zeker GEEN 10x NFS verbetering, véél te veel overhead en limitatie van het NFS protocol.
Met Gigabit ethernet verschenen de NFS schaalbaarheids issues ... dan spreken we nog niet over 10GE ;-)
Welk versie ? 3.x ? 4.x van het NFS protocol ?

[Verwijderd]

jvanhambelgium schreef op vrijdag 24 oktober 2008 @ 12:11:
OK, de LAN ziet er behoorlijk uit.
Ik las dat je beide storage servers als iSCSI target en NFS server heb geconfigged.

Tijdens het copieren van de files, wat dit met NFS of heb je file access via iSCSI gedaan ??
Welke soort file-systems leven er op de verschillende systemen ?

"out-of-the-box" NFS is er al héél wat jaartjes oud en heeft echt wel tuning nodig op "hedendaagse" gigabit & 10 gig links !! NFS werd ontwikkelde in het 10megabits/s ethernet tijdperk.
De NFS-schaling van 100BaseT->Gige gaf zeker GEEN 10x NFS verbetering, véél te veel overhead en limitatie van het NFS protocol.
Met Gigabit ethernet verschenen de NFS schaalbaarheids issues ... dan spreken we nog niet over 10GE ;-)
Welk versie ? 3.x ? 4.x van het NFS protocol ?

Ik heb verschillende methodes geprobeerd om te kopieren. Ik heb geprobeerd via SCP een bestand van 1Gb te kopieren van Server1 ---> Server2. Maximale snelheid 50MB/sec

Via een NFS mount op server1 ook 50Mb/sec.
ISCSI hebben we ook getest. En ook hiet hetzelfde verhaal....

Het ligt dus ook niet aan het NFS protocol!

[FatalError]

Dan had ik het toch mis.. Maar ik vind het goed om te weten dat Netxen haar drivers nu tenminste beter op orde heeft.

[MoBi]

Hum, je lan performace geeft het aan in KBYTE per seconde he!
TCP connection established.
Packet size 1k bytes: 300453 KByte/s Tx, 255950 KByte/s Rx. = 300 MByte per sec & 255 MByte per sec
Packet size 2k bytes: 322682 KByte/s Tx, 254605 KByte/s Rx. = 322 MByte per sec & 254 MByte per sec
Packet size 4k bytes: 326957 KByte/s Tx, 253424 KByte/s Rx. = 326 MByte per sec & 253 MByte per sec
Je lan gaat aardig rap dus tussen de 2 en 3 Gbit per seconde.

Als je echt maar 270 Mbit per sec haalt bij kopieeren is er toch nog steeds iets niet goed of moet dit 270 MByte per sec zijn en zit je dus te stoeien tussen mbit en mbyte per seconde!

[ Voor 5% gewijzigd door MoBi op 24-10-2008 14:46 ]

[jvanhambelgium]

LAN is toch OK ?

300.000 kbytes / sec is toch zo'n 292 megabytes/sec is zo'n 2.4 gigbits/sec

Volgens mij zijn er nog 2 mogelijkheden :

-> limitaties van TCP protocol. Mischien is er nood aan tuning ! (bandwidth-delay product etc)
mischien wat prutsen met mtu's , mss, ..)
-> ergens een limitatie op een "bus" van een systeem ??

Toch altijd wel verdacht dat je zowel voor iSCSI, NFS tegen die magische 50 megabytes / sec aanloopt...

Boeiend probleem!

[MoBi]

jvanhambelgium schreef op vrijdag 24 oktober 2008 @ 14:57:
LAN is toch OK ?

300.000 kbytes / sec is toch zo'n 292 megabytes/sec is zo'n 2.4 gigbits/sec

Volgens mij zijn er nog 2 mogelijkheden :

-> limitaties van TCP protocol. Mischien is er nood aan tuning ! (bandwidth-delay product etc)
mischien wat prutsen met mtu's , mss, ..)
-> ergens een limitatie op een "bus" van een systeem ??

Toch altijd wel verdacht dat je zowel voor iSCSI, NFS tegen die magische 50 megabytes / sec aanloopt...

Boeiend probleem!

Probleem is dat de ts niet heel consequent is met mbyte en mbit per seconde vermeldingen.

[Verwijderd]

Idd, in de eerste post staat 50MB/s en verder op weer 50Mb/s. Wat is het nu? En wat is nu precies je disk config? En waarmee heb je de disk performance getest?

[jvanhambelgium]

Tja, we gaan ervan uit dat we het over 50 megabytes/sec hebben hé, zo'n configuratie (10GE !!) die maar 50 megabits/sec zou onmiddelijk terug de doos in gaan richting vendor ... nu is 50 megabytes/sec ook barslecht maar daar valt nog mee te werken...

Ik denk dat hij gewoon een file-copy heeft gedaan op de storage-server en in een scriptje bijgehouden hoeveel seconden het duurder voor X gigabytes te copieren en dan omzetten naar megabytes/sec ??? Niet volledig representatief, maar toch alvast ietwat indicatief.


Eventueel een andere test : probeer eens vanaf 2 verschillende bronnen tegelijk een file-transfer van/naar een storage-server te doen (dus met 2 clients op gigabit ethernet)

Ben benieuwd of je 2 x 50Mbytes/sec zou halen oid of dat je effectief aan die magische 50 megabytes/sec blijft steken ! (dan kan het of tcp-gerelateerd zijn, of toch iets van bus-limitatie op de storage)

Best lastig dat het in productie staat zodat je niet erg veel kan prutsen...

[MoBi]

jvanhambelgium schreef op vrijdag 24 oktober 2008 @ 17:36:
Tja, we gaan ervan uit dat we het over 50 megabytes/sec hebben hé, zo'n configuratie (10GE !!) die maar 50 megabits/sec zou onmiddelijk terug de doos in gaan richting vendor ... nu is 50 megabytes/sec ook barslecht maar daar valt nog mee te werken...

Die 50 mbyte of mbit kan wel gewoon het max haalbare zijn hoor. 10Ge zegt helemaal niks. Dat is alleen wat het lijntje maximaal aankan. Wil niet zeggen dat de switch het kan verwerken of de netwerkkaart het snel genoeg kan verwerken of de disken het snel genoeg aan kunnen leveren.
De test met netcps sluit de netwerkkaart en switch voor een deel uit. Dus het is de disk config of het os, of de app op het os. Ik vermoed dat het een probleem is dat het niet snel genoeg kan weggeschreven worden. Als het wel naar ram snel genoeg kan worden geschreven. Het kan dus het filesystem zijn de evt virtuele lagen, de belasting van de weg moetn schrijvende server enz.

[ Voor 22% gewijzigd door MoBi op 24-10-2008 20:26 ]

[jvanhambelgium]

MoBi schreef op vrijdag 24 oktober 2008 @ 20:21:
[...]

Die 50 mbyte of mbit kan wel gewoon het max haalbare zijn hoor. 10Ge zegt helemaal niks. Dat is alleen wat het lijntje maximaal aankan. Wil niet zeggen dat de switch het kan verwerken of de netwerkkaart het snel genoeg kan verwerken of de disken het snel genoeg aan kunnen leveren.
De test met netcps sluit de netwerkkaart en switch voor een deel uit. Dus het is de disk config of het os, of de app op het os. Ik vermoed dat het een probleem is dat het niet snel genoeg kan weggeschreven worden. Als het wel naar ram snel genoeg kan worden geschreven. Het kan dus het filesystem zijn de evt virtuele lagen, de belasting van de weg moetn schrijvende server enz.

Euh .. heb je de specs van de storage server al eens gelezen ?????
50 mbits "performance" = inpakken en door de leverancier z'n raam smijten !!!
We spreken hier niet over een hobby-bob NAS maar toch iets waar je net iets meer van mag verwachten.
Akkoord, het is nog lang geen hitachi,emc³ of netapp maar toch...

M'n vroegere zelfgemaakte NAS op basis van Gentoo64 met een Areca PCI-E controller met 8 x 400GB SATA schijven deed grofweg 80MBytes/sec read (1 x gigabit link) met 1 client out-of-box in een RAID5 configuratie.

[Gomez12]

Btw, hoe wordt dit gemeten?

Want als het een productie omgeving is waarin gewerkt wordt dan vind er zeer waarschijnlijk niet alleen maar die ene kopieer actie plaats.
Als je nog 100 mensen hebt die hun profielen en data op die storage hebben staan en gebruiken dan zijn sowieso je metingen altijd incorrect.

[Kokkers]

Laten we in PNS in iedergeval de bits en de bytes niet door elkaar halen.

80Mbytes/sec read? Lokaal? Over welk protocol? Waar naar toe?
Zolang er geen specificatie van het probleem wordt gegeven is het appels met peren vergelijken en kunnen we dit topic net zo goed sluiten.

Met block level access als iSCSI moet je op gigabit met fatsoenlijke disks en hardware tegen 90% van wirespeed kunnen komen. Mijn ervaring is dat voor NAS single-transfer kopie akties het gebruikte protocol vaak de bottleneck is. NFS is net iets efficienter en sneller dan CIFS maar ook maar marginaal.

Als voorbeeld:
Tussen 2 beefy Windows 2003 x64 Enterprise servers haal ik over Windows file sharing protocol (CIFS as you please) tussen 2 RAMdisken (2300MB+/sec seq. read benchmarked), Foundry dedicated gigabit switch en Intel Pro 1000 kaarten ook maar krap 40-50Megabyte per seconde aan snelheid bij een enkele file kopie aktie. Dit is dan in default configuratie en met een iPerf bench die zegt dat 970Mbit mogelijk zou moeten zijn. Jumbo frames en tweaks kunnen nog wel een tikje verbeteren maar verwacht hier geen wonderen van.
Ik denk dan ook niet dat je bij enkele kopie akties zoals je die wellicht test voordeel zal hebben van CX-4 t.o.v. GbE. Als er 1000 man aan moet komen hangen is het een ander verhaal natuurlijk en zul je je bandbreedte hard nodig hebben mits alle tussenliggende schakels ook de performance kunnen leveren.
Met andere woorden, bedenk welke eisen je hebt stel een representatieve test op

De meeste TCP performance tweaks zijn in Windows Server 2003 SP2 al wel doorgevoerd en een hoop van de 'registry changes' kunnen meer kwaad dan goed doen als je niet grondig test. TCP Window scaling is default al goed geregeld en delayed TCP ACK's kunnen ook voor andere onbekende problemen zorgen. Elke fatsoenlijke netwerkkaart biedt mogelijkheden voor 'Receive side scaling' en heeft een TCP Offload Engine (TOE). Als iemand dit niet met me eens is ben ik een-en-al oor voor mogelijke suggesties.

De TCP stack van Window Server 2008 (is net als die van Vista) geoptimaliseerd voor 'verbeterde performance'. Zie ook http://technet.microsoft....rary/bb878108(en-us).aspx. Exacte gegevens van de verbeteringen zijn mij echter niet bekend. Voor linux fileservers geldt vaak 'performancegarantie tot op de hoek'. Ik heb dramatische performance gezien door bijvoorbeeld slechte driversupport maar ook linux fileservers die substantieel sneller zijn dan Windows fileservers. Van high-end turn-key oplossingen mag je verwachten dat ze goede snelheid leveren maar daar zul je ook stevig voor moeten betalen.

Ik heb me ook al heel vaak afgevraagd waarom file level netwerktoegang in de wereld van gigabit+ netwerken nog steeds zo traag moet zijn. Het zou vandaag de dag toch geen rocketscience meer moeten zijn om op lokale low-latency netwerken gewoon fatsoenlijke transfer rates te halen? Waar knelt de schoen?

Hoewel de 10Gigabit techniek nu steeds meer binnen bereik komt blijft het wel een nieuwe techniek. Zoals gezegd wordt deze ingezet voor software en protocollen die ontworpen zijn om op 10 a 100Mbit te werken.

Maargoed, zolang de exacte case van de topicstarter niet duidelijk is kan niemand hier iets zinnigs over zeggen. Ik heb het gevoel dat je voor een paar duizend euro wat spullen hebt gekocht met het 10Gbit label erop en hebt gedacht 'dit doe ik wel even'. In de praktijk snijd je je hier soms mee in de vingers en soms zit je voor een dubbeltje op de eerste rang. Het alternatief is dat je alsnog een clustered NAS head met SAN back-end en toeters en bellen koopt. Bijkomend voordeel; de kosten die je al hebt uitgegeven vallen in het niet bij de offerte die je dan mag laten tekenen .

Ik ben benieuwd naar je bevindingen, kunnen we allemaal van leren.

[ Voor 3% gewijzigd door Kokkers op 24-10-2008 22:45 ]

[Kabouterplop01]

Sowieso nooit netwerkbenchesbeginnen te doen met TCP; dit heeft zeker op 10G een hoge overhead.
Je wilt graag weten wat je machines en je netwerk kunnen, dan moet je eerst met UDP testen.
Hoe staan die ports op de switch ingesteld? Zie je daar errors? En wat voor link state zie je op die switch terwijl je NIC's op auto staan?
zet alle interfaces eens allemaal op autoneg met een test en dan alle interfaces eens op no autoneg.
Soms wil dat onderhandelen wel eens flink mis gaan, dan zal je link speed wel 10G aangeven maar is je sliding windowsize helemaal niks.

[ Voor 28% gewijzigd door Kabouterplop01 op 25-10-2008 01:27 ]

[Gomez12]

Kabouterplop01 schreef op zaterdag 25 oktober 2008 @ 01:17:
Sowieso nooit netwerkbenchesbeginnen te doen met TCP; dit heeft zeker op 10G een hoge overhead.
Je wilt graag weten wat je machines en je netwerk kunnen, dan moet je eerst met UDP testen.

Tsja, ik zal wel raar zijn, maar theoretische snelheden hebben mij nooit zo geinteresseerd.
Als ik 99% van mijn verkeer over TCP heb lopen dan boeit de UDP snelheid mij persoonlijk echt niets.

Qua troubleshooting heb je wel gelijk, maar qua netwerkbenches imho totaal niet. Een netwerkbench hoort de realiteit weer te geven en niet een mooi getal wat opgaat voor 0,01% van mijn verkeer...

[Kabouterplop01]

Tsja, ik zal wel raar zijn, maar theoretische snelheden hebben mij nooit zo geinteresseerd.
Als ik 99% van mijn verkeer over TCP heb lopen dan boeit de UDP snelheid mij persoonlijk echt niets.

niet raar, maar waarschijnlijk een server man ipv een netwerkman.
Met UDP (ervan uitgaande dat je machines goed ingesteld staan) maak je je baseline.(Daar is niets theoretisch aan. Het is gewoon net zoals met TCP een realtime test. a.d.h.v de overhead die TCP gebruikt kun je gaan uitrekenen en vergelijken met de TCP tests wat je netwerk elementen kunnen verstouwen.
Overigens had ik het indirect al over TCP; UDP heeft geen sliding Window. En NFS is UDP

[ijdod]

Kabouterplop01 schreef op zaterdag 25 oktober 2008 @ 01:17:
Sowieso nooit netwerkbenchesbeginnen te doen met TCP; dit heeft zeker op 10G een hoge overhead.
Je wilt graag weten wat je machines en je netwerk kunnen, dan moet je eerst met UDP testen.
Hoe staan die ports op de switch ingesteld? Zie je daar errors? En wat voor link state zie je op die switch terwijl je NIC's op auto staan?
zet alle interfaces eens allemaal op autoneg met een test en dan alle interfaces eens op no autoneg.
Soms wil dat onderhandelen wel eens flink mis gaan, dan zal je link speed wel 10G aangeven maar is je sliding windowsize helemaal niks.

TCP heeft op 10 GbE geen hogere overhead dan op 1 GbE, of zelfs 10 MbE. De overhead is simpelweg een percentage van de payload, en dat percentage blijft gelijk. Wat je vermoedelijk bedoelt is dat TCP (en in principe elk connection oriented protocol) gevoelig is voor latency (RTT, "ping"). Even kort door de bocht heeft een TCP sessie over 10 GbE met een max window size van 64K, en een RTT van 0,1 ms, een effectieve bandbreedte van zo'n 5 Gbps. De overige 5 Gbps zijn gewoon beschikbaar; met twee van dergelijke sessies kan je de link dus vullen.

Op 1 GbE was dit een vaak een instinker bij twinning. Men maakt een tweede rekenvloer, dark fibertje er tussen, en is dan hoogst verbaast dat de performance van 800-900 Mbps dropt naar ca 150 Mbps. Bij 10 GbE wordt het zelfs binnen je vloer mogelijk een issue.

Errors is het goed punt. Link state minder; link state is aan of uit. Negotiation is geen issue op 10 GbE.

[jvanhambelgium]

Kabouterplop01 schreef op zaterdag 25 oktober 2008 @ 12:13:
[...]
Overigens had ik het indirect al over TCP; UDP heeft geen sliding Window. En NFS is UDP

NFS hoeft helemaal niet uitsluitend UDP te zijn. De idee was (in versie 2) om uitsluitend UDP te gebruiken vanwege z'n "stateless" aard en zaken als file-locking buiten het core protocol te houden.

NFS over WAN links bijvoorbeeld worden veel over TCP gedaan (versie 2 & 3 & 4)

Nu met de laatste 4.x updates begint ook pNFS (parallel nfs) z'n intrede te doen.

[Kabouterplop01]

Overigens met die link states geef ik je gelijk er is link of niet . ik doelde meer op het negotiation gedeelte zelf.
Ik heb het met 10G (daar ken ik ze alleen met DWDM apparatuur) nog niet meegemaakt maar wel met Gi en Fa dat je 4 interfaces (2x switchp, 2x serverport) op auto zet en dat de ene kant van de 2 "connected" is met FD en de andere onderhandelt op HD . Zelfde apparatuur (servers) en zelfde switches. kabeltje omwisselen of poortje omprikken zelfde beeld.. Dit is trouwens iets wat ik nog niet met fibers heb gezien, alleen met koper.

[StAvOx]

Geen idee aan wat voor switches de machines hangen, maar toch doe ik een poging.. Zou het niet zo kunnen zijn dat er wat op die core switches aan acl's flink dwarszit? Dus zodra er 'normaal' netwerkverkeer doorheen moet deze via een langzame routing engine gestuurd wordt doordat de switch acl's tegenkomt die ie niet op z'n snellere lagen kan verwerken oid?

Ik heb trouwens met nfs v3+4 gewoon met 110 Megabyte/sec op een gigabit link kunnen schrijven hoor. Tussen solaris en linux zonder tuning of jumbo frames..

[ Voor 18% gewijzigd door StAvOx op 31-10-2008 00:06 . Reden: nfs verhaal toevoegen ]

[Guru Evi]

Ik haal ongeveer hetzelfde tussen 4-jaar oude servers op een gigabit link (50 MByte/s) naar een setje van 7 RAID5 PATA 133 disks maar daarvoor heb ik wel moeten testen en prutsen met sysctl. Mijn aanpassingen in sysctl:

net.inet.ip.intr_queue_maxlen=500
net.inet.tcp.sockthreshold=512
net.inet.tcp.delayed_ack=0 #Met dat ging het vooral stukken sneller
net.inet.tcp.mssdflt=1460
net.inet.tcp.sendspace=65535
net.inet.tcp.recvspace=65535
net.inet.tcp.newreno=1 #Dat maakte het ook een stuk beter

10 gigabit is wel enorm breed voor slechts 1 of 2 setjes disks ik zou niet verwachten om meer dan een gigabit te kunnen halen.

En dan natuurlijk het obvious: Hoeveel CPU wordt er verbruikt als je aan de top komt? Wat is je packet size. Ik kom niet hoger op mijn Ethernet zonder te switchen naar Jumbo packets maar Jumbo wordt niet ondersteunt door een deel van het netwerk (100 Mbps delen) dus ik kan niet zomaar veranderen. Het kan zijn doordat je pakketjes te klein zijn, dat je switches (ik ben niet bekend met wat jij gebruikt) of je netwerkkaarten gaan vollopen met pakketjes en die niet in tijd kunnen afhandelen (kijk na hoeveel dropped packets er zijn).

Er zijn een hoopje handleidingen om NFS performance te verhogen, wat krijg je daardoor? Mounten met async en NFSv3 over TCP gebruiken gaat beter dan de 'standaard' maar je moet ook weten wat er gebeurt als er iets misgaat als je dat aanzet.

[Verwijderd]

Bij een klant van mij heb ik precies zo'n probleem!
Zelfde NIC's echter met een procurve 5406 Switch. Wat wij ervaren is vooral dat er heel erge vertraging op de exchange server aanwezig is. Outlook clients communiceren zeer traag richting de Exchange server op de 10 GB, terwijl het over de 1GB 'vliegt'.

Volgende week vrijdag komt HP onsite (2 man) met ondersteuning vanuit India om het probleem te bekijken. HP heeft toegegeven dat er problemen zijn met deze kaarten.

Voor ons even afwachten tot vrijdag.