Skrivet av Stenull:
Hmm vad har du för diskar?? Jag kopierade 1TB från en FreeNas på 4*500GB diskar i RADIZ1 med 8GB minne till FreeNas med 5*3TB diskar i RAIDZ1 och 16GB minne över 1GB nät. mitt snitt blev 456Mb/s alltså knappt en halv Gbit. Ungefär där läsning från 4 mekaniska diskar i RAIDZ1 bör ligga om jag minns rätt...
Hur fan lyckas du maxa en 1Gb lina med två mekaniska diskar? 15K spinnare? låter ändå lite väl mycket...
btw du menar 2*3TB väll?
När data läses från en ZFS-spegel nyttjas samtliga diskar i samma spegling. För två diskar med en konstant läshastighet på ca 100 MB/s innebär det en teoretisk maximal läshastighet på 200 MB/s för en tvåvägsspegel, 300 MB/s för en trevägs. När jag läste denna tråden blev jag tvungen att själv testa lite mot en spegel med 2x 3TD WD Red där läshastigheten via SMB/Samba konstant låg runt 100 MB/s till min desktop. (Skrivhastigheten var också i snarlik hastighet utan att diskarna fick jobba fullständigt. Med dd kom jag upp i högre hastigheter än vad 1 Gbit.)
Det finns dock mycket annat som påverkar överföringshastigheten än bara diskuppsättningen:
Kontrollerkort
Övrig belastning på systemet
Fragmentering i lagringen (gäller för både server och klient)
Nätverkshårdvara som i nätverkskort, switchar samt firmware och drivrutiner till dessa (ett vanligt problem som påverkar nätverksbaserad överföring)
Protokoll så som Samba, SMB, NFS, iSCSI, dess implementationer samt versioner
Nu kan också enskilda hårddiskar krångla. I FreeBSD/FreeNAS rekommenderar jag övervakning av dem genom t.ex. gstat. Är hastigheten låg kan t.ex. en hårddisk jobba mycket mer än övriga (ligger vanligtvis nära 100% hela tiden samtidigt som övriga kanske ligger på 50%). Detta var mycket användbart när jag kunde se krånglade diskar i en egen raidz som jag har hemma. Efter att de diskarna hade bytts ut blöev prestandan märkbart bättre.
Skrivet av tomle:
Du blandar ihop Gbit och GB. Halv Gbit ~ 60MB/s vilket är långt under vad man kan läsa i RAIDZ1 (däremot så är läshastigheten i RAIDZ1 lika med läshastigheten för den långsammaste disken så om dina 500GB-diskar inte klarar mer än 60MB/s så är det väl rimligt).
En modern disk kan läsa i över 100MB/s vilket fyller en Gbit-lina men det gäller förstås att mottagaren kan ta hand om datat lika snabbt. RAIDZ1 har ju viss performance penalty även vid skrivning.
Likt ZFS-speglar är läshastigheten i form av bandbredd är en ackumulering av samtliga diskars bandbredd, inklusive paritet, i en raidz utifrån vad jag kunnat observera. Däremot är det helt rätt att I/O per sekund (IOPS) begränsas till den långsamaste hårddisken i en raidz (egentligen en vdev men en raidz kan endast vara en vdev och inget annat). IOPS kan givetvis påverka hastigheten beroende på hur fragmenterad lagringen är, vad för data som läses samt att checksummor ska verifieras, med flera.
Jag gjorde nyss ett eget test hemmavid med min raidz bestående av 3x 4TB HGST 7200RPM. Enskilt klarar de av läsning och skrivning upp mot ca 170 MB/s och troligtvis mer IOPS än t.ex. WD Red på grund av rotationshastigheten. Vid läsning över SMB/Samba som i runda slängor låg konstant över 100 MB/s så lästes det konstant ca 30-40 MB/s från varje enskild disk. I detta fall var det bulkdata som ej var särskilt fragmenterad vilket innebar att diskarna inte ens var i närheten av att svettas. Med gstat kunde jag se att de jobbade i ca 30-50% (varierade givetvis en del).
Skrivet av Stenull:
Min hjärna hade nog inte startat ordentligt i morse.. Ändå skumt att min överföring inte kom upp i mer än 0,45Gbit/s
Kollar jag på mottagarens skrivprestanda så är sämsta resultat 65.1MB/s (vet inte hur jag skall räkna ut en teoretisk skrivprestanda men gör ett försök, det haltar säkert).
5 diskar i RADIZ1 kan man säga att man har 4 tillgängliga.
4* 60MB/s (tog bort 5MB/s för att kompensera lite) = 240 MB/s = 1920 Mb/s, alltså borde mottagaren med råge kunna svälja vad som går att leverera över min lina :/
Där är säkert en tankevurpa ovan, hur hade ni räknat?
Får hem och göra lite tester, fundera och läsa lite i lugn och ro över julhelgen.
Som jag skrev ovan så är räkning nog korrekt förutsagt att samtliga diskar kan upprätthålla en läshastiget i ca 60 MB/s. Ta gärna en titt i gstat på båda sidor för att se att inga hårddiskar agerar flaskhals. Hur utfördes överföringen? Var det via Samba, NFS, scp/rcp, eller kanske ZFS send/receive? Scp eller ZFS send via ssh kommer t.ex. innebära begränsning för kryptering och dekryptering vilket klart påverkar prestandan (där hamnar jag runt ca 50 MB/s på samma datorer som klarar av att maxa linan via Samba/SMB).
Vid skrivning av mycket data kan även metaslabs i ZFS spela roll. Har man många tomma metaslabs innan överföring kan de utnyttjas istället för att fylla upp redan användna som kan ha allt mellan 10 MB och 10 GB ledigt. Vid byte av metaslab krävs ny sökning på hårddiskarna (IOPS) vilket i sin tur påverkar skrivhastigheten. Är datan man läser väldigt utspridd (fragmenterad) kommer det även påverkar läsning. Nu har jag tyvärr inte kvar länkarna om detta men med lite googlande bör man kunna hitta dem igen.
För att kolla hur ens metaslabs ser ut på en pool kör man:
I min raidz-pool hade jag tidigare 3x 2TB som användes en hel del. De nfylldes aldrig upp men data skyfflades ofta undan, togs bort eller lades till. Efter byte av varje disk till 4TB har jag nu dubbla lagringskapaciteten i samma poo (detta slutfördes rätt nyligen)l. Vid en titt på metaslabsen kan man se att efter ungefär hälften av dem är nästan samtliga helt tomma medan de tidigare varierar stort (skiftet sker vid metaslab 174 av 348 st):
vdev 0
metaslabs 349 offset spacemap free
--------------- ------------------- --------------- -------------
metaslab 0 offset 0 spacemap 33 free 14.0G
metaslab 1 offset 800000000 spacemap 34 free 10.2G
metaslab 2 offset 1000000000 spacemap 42 free 1.22G
metaslab 3 offset 1800000000 spacemap 43 free 1.37G
metaslab 4 offset 2000000000 spacemap 44 free 1.31G
metaslab 5 offset 2800000000 spacemap 45 free 10.2G
metaslab 6 offset 3000000000 spacemap 46 free 12.5G
metaslab 7 offset 3800000000 spacemap 49 free 1.22G
metaslab 8 offset 4000000000 spacemap 50 free 980M
...
metaslab 163 offset 51800000000 spacemap 1647 free 1.24G
metaslab 164 offset 52000000000 spacemap 283 free 12.6G
metaslab 165 offset 52800000000 spacemap 1813 free 29.8G
metaslab 166 offset 53000000000 spacemap 1929 free 1.51G
metaslab 167 offset 53800000000 spacemap 2172 free 27.7G
metaslab 168 offset 54000000000 spacemap 133 free 21.2G
metaslab 169 offset 54800000000 spacemap 134 free 32.0G
metaslab 170 offset 55000000000 spacemap 137 free 28.6G
metaslab 171 offset 55800000000 spacemap 139 free 16.2G
metaslab 172 offset 56000000000 spacemap 140 free 20.6G
metaslab 173 offset 56800000000 spacemap 141 free 9.8G
metaslab 174 offset 57000000000 spacemap 0 free 32G
metaslab 175 offset 57800000000 spacemap 0 free 32G
metaslab 176 offset 58000000000 spacemap 0 free 32G
metaslab 177 offset 58800000000 spacemap 0 free 32G
metaslab 178 offset 59000000000 spacemap 0 free 32G
metaslab 179 offset 59800000000 spacemap 0 free 32G
...
metaslab 344 offset ac000000000 spacemap 0 free 32G
metaslab 345 offset ac800000000 spacemap 0 free 32G
metaslab 346 offset ad000000000 spacemap 0 free 32G
metaslab 347 offset ad800000000 spacemap 0 free 32G
metaslab 348 offset ae000000000 spacemap 0 free 32G
Metaslabsen kanske inte behöver säga något men kan nog ändå ge en indikation på hur det kan bete sig, eller varför det beter sig som det gör.
Vid felsökning rekommenderar jag att titta på följande:
Testa bandbredd med hjälp av iperf mellan noderna. Gärtna åt båda håll samt med olika "fönster storlekar". Exempelvis följande varianter på klientsidan:
iperf -c <server>
iperf -c <server> -w 64K
iperf -c <server> -w 64K -P 2
iperf -c <server> -w 64K -P 10
iperf -c <server> -w 128K
Jag misstänker att det i samtliga kombinationer ej kommer att nå upp till en Gbit. Dock värt att kolla och se att bandbredden ens kan komma i närheten av det. Parametern "-P" anger antalet simultana överföringar (1 som standard) och "-w" är fönsterstorlek som anger hur stora chunkar data som skall skickas (standard är 8K).
Försök att undvika integrerade nätverkskort från t.ex. Realtek. Även om det ibland kan fungera som det ska för vissa så kan det ändå bli problem. T.ex. har jag själv ett i min desktop men prestandan varier stort beroende på hur jag utför nätverksöverföringen. Skriver jag till en specifik hårddisk går det väldigt stötvis trots att den hårddisken utan problem kan skriva bra kontinuerligt (kan eventuellt ha med kontrollerkort på desktop, dåliga drivrutiner eller liknande att göra).
Det kan även vara andra saker så som att RSS ej är påslaget eller andra konstiga beteenden pga nätverkskort, drivrutiner och firmware.
Övervaka diskaktivitet med hjälp av gstat. Då gstat listar alla blockenheter (hårddiskar, partitioner, zvols, glabels, krypterade enheter, m.fl.) så är det bekvämt att köra med ett filter, t.ex. följande för att endast se hårddiskar i form av ada eller da:
Sticker någon eller några diskar ut över en längre tid kan det vara ett tecken på att något inte fungerar som det ska. Stora variationer kan ofta förekomma så att t.ex. en hårddisk tillfälligt jobbar i 100% medan övriga knappt jobbar behöver inte innebära något problem.
Vanligtvis används dd av många för att mäta hur snabb man kan skriva eller läsa till en zpool. Man ska dock vara försiktig med de resultaten ibland i och med att data lätt cachas upp vilket påverkar testade läshastigheter (gäller även skrivning om filsystemscache är tillgängligt). För att inte tala om att man lätt kan förstöra data om man inte hanterar det väl. För en snabb indikation tillsammans med gstat kan det dock vara bra. dd har en förmåga att belasta hårddiskar väldigt mycket och då kan man ibland se vad hur vissa diskar beter sig när de belastas hårt.
Testa olika protokoll. T.ex. är Samba väldigt singeltrådat vilket kan agera flaskhals. Med NFS kan man utföra asynkrona skrivningar och ange i hur stora chunkar data ska läsas/skrivas vilket kan ge en ytterligare prestandaboost.
Som avslutande ord så känns ZFS som en helt vetenskap. Det finns otroligt mycket man måste hålla reda på för att få till och bibehålla bra prestanda/funktionalitet för just sina behov. Min rekommendeation är att se till att läsa på samt labba mycket innan man börjar köra det i "produktion" då det finns mycket i ens behov och utrsutning som påverkar. Exempelvis finns det saker jag gärna hade gjort annorlunda i min filserver i och med vad jag lärt mig sedan jag satte upp den för snart två år sedan.
Nu har jag dock suttit med detta i två timmar så dags att sova! Visserligen måste man väl inleda sin julledighet
EDIT: Typo.
