@javcon
Ik ben een beetje kwijt wat je oorspronkelijke probleem was. Misschien kan je dat nogmaals even beknopt posten.
Hierbij in ieder geval een stappen plan hoe zfs send / receive te optimaliseren.
Grof weg zijn er 5 punten die bekeken moeten worden
-Kan zfs send voldoende snel de data aanleveren?
-Kan de netwerk zender de data voldoende snel versturen?
-Kan het netwerk (tcp/ip & driver op de zender, netwerk zelf en driver & tcp/ip op de ontvanger) wel de datastroom verwerken?
-Kan de netwerk ontvanger de data voldoende snel ontvangen?
-Kan zfs receive de data voldoende snel wegschrijven?
Als eerste DISABLE iedere vorm van power safe, C-states, frequency scaling. De systemen moeten voor de baseline testen altijd op volle snelheid draaien.
Begin onderaan met ruwe tcp transfer snelheid te meten. Als je weet dat je tcp met wirespeed kan verwerken heb je een goed indicatie dat er geen obstakels zijn. Niet dat het betekent dat iedere applicatie vervolgens op wirespeed kan communiceren.
De manier om een eerste indruk te krijgen is mbv iperf en een cross cable. Die cross cable elimineert de switch als factor.
Begin met een default mtu van 1500 en in het geval van ethernet geen jumbo frames en disable alles van offloading en andere acceleratie in de driver. Maak eventuele tweaks in sysctl ofzo ook ongedaan. En reboot.
Nu kan je een baseline vaststellen. De baseline vertelt je hoe de prestaties zijn van het os, drivers en nic out of the box.
server# iperf -s -f m -m -i 5
client# iperf -c server -f m -m -i 5 -t 60
-s server mode
-f m report in megabits/sec
-m print mss en mtu
-i 5 print output om de 5 sec
-c server maak verbinding met server
-t 60 voer een test van 60 sec uit
Is de snelheid te laag kijk dan naar je TCP window size. Je kan deze in iperf vergroten bijv -w 130k. LETOP je kan je TCP window size niet onbeperkt vergroten je OS moet het aankunnen.
Tijdens de test hou je systeem in de gaten met bijv top. Kijk in top of het systeem niet overbelast wordt. Haal je nu wirespeed dan kan je daarna gaan kijken of je de load van je systeem kan verlagen. Je kan kijken of bepaalde offload features in de driver een verbetering opleveren. Je kan kijken of jumbo frames wat opleveren. Jumbo frames verlagen het aantal interrupts per sec. Moderne systemen hebben dankzij interrupt coalescing hier minder last van. Als je de laagste overhead wil dan moet je jumbo frames gebruiken.
Houd er rekening mee dat sommige aanpassingen een reboot vereisen. Letop dat je jumbo frames niet terecht komen op je wan bijv of je clients want dat werkt niet. Jumbo frames zou je alleen moeten gebruiken op een niet routeerbaar lan segment, bijv als esx storage traffic of een dedicated zfs send/receive segment. Met vlans kan je dit mooi isoleren.
Als je tevreden bent met het behaalde resultaat verwijder dan de cross cable en plaats de switch ertussen en test opnieuw om vast stellen dat er geen degradatie is opgetreden.
10Gigabit en infiniband.
Veel OS'es zijn niet voldoende out-of-the-box voorbereid op deze snelheden, evenmin sommige mobo's.
Om 10gb vol te duwen heb je minsten 1.25GB/sec nodig aan bandbreedte over je pcie. Zit de nic net in een verkeerd slot dan kan het wel eens niet optimaal werken. Ik kan hier geen specifieke tips geven want daarvoor zijn er teveel OS's. Wel is het in de meeste gevallen nodig om parameters aan te passen, waaronder read en write buffers heel erg te vergroten. Ik moet soms 10-20 dingen aanpassen om het onderste uit de kan te krijgen. Vergeet niet dat je settings wel compatible moeten zijn als je verschillende OS's door elkaar gebruikt. Letop dus op dat je niet iets optimaliseert tussen twee servers en dat je clients het vervolgens niet meer doen.
Als je tevreden bent met je netwerk en hebt gemeten wat je maximaal aan bandbreedte hebt kan je transfer applicatie gaan testen. De transfer applicatie leest van stdin, doet er optioneel iets (compressie of encryptie) mee, en verstuurd het via tcp naar de ontvanger die het proces omkeerd en de data naar stdout schrijft.
Veel gebruikte applicaties zijn ssh, nc en mbuffer.
SSH werkt prima alleen is het lastig echt hoge snelheden (meer dan 1 gbit) te behalen. Voor send/receive over WAN lijkt het mij de aangewezen tool.
nc (netcat) is de meest simpele tool. Het leest van stdin en schrijft naar een socket toe. De ontvanger piped de data naar stdout.
mbuffer is een geavanceerde versie van netcat. De belangrijkste meerwaarde is de buffering. Een bursty karakter kan worden glad gestreken en het netwerk kan constant worden belast.
server# mbuffer -s 128k -m 1G -I 5001 > /dev/null
client# dd if=/dev/zero bs=1M count=10000 | mbuffer -s 128k -m 1G -O server:5001
Luister op de server op poort 5001 (de iperf poort) met een buffer van 1GB en een blockgrootte van 128KB
Verstuur 10GB vanuit dev/zero door mbuffer naar de server.
Afhankelijk van je netwerk snelheid moet je misschien je buffersize vergroten alsmede blocksize.
Je moet met deze test dezelfde snelheden als iperf kunnen behalen.
Wederom houd je systeem goed in de gaten qua belasting.
Nu zfs, voordat je begint met overdracht via het netwerk stel je eerst de zfs send baseline vast.
client# zfs send -R mpool@snapshot > /dev/null
of
client# zfs send -R mpool@snapshot | dd bs=1M of=/dev/null
in andere vensters monitor je systeem bijv # top en # zpool iostat mpool 5 Vooral die laatste zal uitwijzen hoeveel profijt je hebt van mbuffer en of je disks voldoende snel zijn om het netwerk van data te voorzien.
Na deze test weet je hoelang het minimaal duurt om je gegevens over te zetten. Het zal nooit sneller gaan over het netwerk dan dit. Is dit (aflezen van de dd output) langzamer dan je netwerk snelheid dan zal je wat aan je vdevs moeten doen, meer vdevs, andere layout of snellere disks.
Ik heb even een testje gedaan op de volgende pool
code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
| wes$ zpool list -v mpool
NAME SIZE ALLOC FREE EXPANDSZ CAP DEDUP HEALTH ALTROOT
mpool 3.62T 1.09T 2.54T - 30% 1.00x ONLINE -
mirror 1.81T 557G 1.27T -
c1t50024E9204294EE5d0 - - - -
c1t50024E900499258Fd0 - - - -
mirror 1.81T 557G 1.27T -
c1t50024E9004992426d0 - - - -
c1t50024E9004992406d0 - - - -
c3t3d0 1008M 1.50M 1006M -
wes$ pfexec zfs send -R mpool@20131014 | dd bs=1M of=/dev/null
29+78636479 records in
29+78636479 records out
1121265666080 bytes (1.1 TB) copied, 6452.31 s, 174 MB/s |
Op dit systeem zal je nooit een hogere snelheid dan gemiddelde 174 MB/sec behalen anders gezegd het zal nooit korter duren dan 6452 seconden. Op sommige moment werd er met 300MB/sec gelezen op andere maar met 60MB/sec. ZFS send vertoont niet dezelfde karakteristiek als dd die een disk van lba 0 tot het einde leest. ZFS send parsed de metadata bouwt zo een geordende datastroom op, dit levert veel random io op. Dit toont ook aan om je testen uit te voeren op realistische data. Verschillen in data kunnen tot grote performance verschillen leiden.
Je (L2)ARC kan een positieve bedrage leveren. Even je ARC hit/miss ratio bekijken met # kstat -pn arcstats voor meer info.
De voorlaatste test. Het optimaliseren van de verzender.
server# mbuffer -s 128k -m 1G -I 5001 > /dev/null
client# zfs send -R mpool@snapshot | mbuffer -s 128k -m 1G -O server:5001
in andere vensters monitor je systeem weer # top en # zpool iostat mpool 5
Nu weet je wat de maximale overdracht snelheid is. Dit zou of net zo snel moeten zijn als zfs send of de eerder gemeten maximale netwerk snelheid.
Laatste stap
server# mbuffer -s 128k -m 1G -I 5001 | zfs recv -vFd mpool
client# zfs send -R mpool@snapshot | mbuffer -s 128k -m 1G -O server:5001
Nu meet je hoe snel de ontvanger het kan wegschrijven. Zie je buffer overruns dan kan de ontvanger het niet snelgenoeg wegschrijven, pas wederom je vdevs aan, meer vdevs, snellere disks.
Als laatste moet je rekening houden met het soort data, veel kleine files zijn trager dan grote streams bij zfs send/recv.
Pas als alles naar je zin is mag je eerder uitgezette energie besparende features weer aanzetten. En kijken hoeveel het scheelt.
Deze method is natuurlijk ook voor andere situaties van toepassing als SMB, NFS en iSCSI. Al is het lastiger om die protocollen te optimaliseren. ZFS send/recv is veruit de makkelijkste.
Succes
Update1: Voorbeeld benchmark van zfs send naar dev/null
[
Voor 10% gewijzigd door
tvwes op 05-04-2015 19:01
]
:fill(white):strip_exif()/i/2003943496.jpeg?f=thumbmini)
:strip_exif()/i/1321263566.png?f=thumbmini)
:strip_icc():strip_exif()/u/53680/steiner.jpg?f=community)
/u/217664/crop57a47149436c0_cropped.png?f=community)
:strip_icc():strip_exif()/u/92426/garfield_avatar.jpg?f=community){kind=avatar}
Volgende waar ik tegenaan liep van was dat de performance blubber was. Schijnbaar vind virtio-scsi de CFQ scheduler niet leuk, omgezet naar deadline op de host en nu bare-metal throughput in de VM.
:strip_exif()/u/70909/BlueKachina_60x60.gif?f=community)
), maar ik zou het even dubbelchecken.
:strip_exif()/u/396800/D-_3427da0a9c293b63f2a66dea2e642102.gif?f=community)
/u/4739/logo-clean-icon.png?f=community){kind=icon}
:strip_exif()/u/29037/sousuke02a.gif?f=community)
:strip_exif()/u/340453/crop67a669ce4f1f4_cropped.webp?f=community)
:strip_exif()/u/26026/snowrabb.gif?f=community)
/u/170728/owl.png?f=community)
:strip_icc():strip_exif()/u/600274/avatar.224756.60x60.jpg?f=community){kind=avatar}
:strip_icc():strip_exif()/u/6607/klootviool2.jpg?f=community)
:strip_icc():strip_exif()/u/53553/hiddink.jpg?f=community)
:strip_icc():strip_exif()/u/8072/70px-SHODAN.jpg?f=community)
/u/102334/avatar_mini.png?f=community){kind=avatar}
:strip_icc():strip_exif()/u/27112/bierflesje_avatar.jpg?f=community){kind=avatar}