| 2012-05-08, 20:55 | #1 |
ZyntaXMedlem Plats: X Registrerad: aug 2003 |
Råd för att få bättre fart på NFS (ESXi 5, Openindiana)
Har kastat ihop en All-in-one ESXi server relativt nyligen på gammal hårdvara jag redan hade bestående av:
Moderkort: Asus P6T Deluxe v2 CPU: i7 920 24gb minne Köpte till: IBM ServeRAID M1015 SAS kort och flashade IT firmware (passthrough till OI). Intel 520 180gb SSD för ESXi och VMs. 6st Seagate Barracuda ST3000DM001 3TB diskar. (inte optimalt diskantal med 4k sektorer tyvärr). ESXi har alla patchar (5.0.0, 702118). Som lagrings OS kör jag Openindiana 151a3 Sen kör jag Ubuntu 11.10, Windows 7 och OSX på maskinen. VMWare tools installerat på alla VMs och VMCI unrestricted på alla VMs. Kör VMXNET3 på alla VMs. Jag gjorde en raidz pool med 4k alignment i zfsguru och importerade i OI. Fungerade bra efter lite meck. Internt presterar raiden mycket bra. Bonnie++ ger seq read/write på ~900/800MB/s. Sen valde jag att dela ut till VMs och på trådat gigabit nätverk med NFS. Trodde att jag skulle få flygande prestanda mellan VMs tack vare VMCI och VMXNET3 men har inte lyckats helt. Först körde jag med E1000 istället för VMXNET3 för läste att Openindiana kunde få dåliga prestanda med E1000. Jag fick usla prestanda med E1000. 40-50MB/s till Ubuntu via nfs4. Testade CrystalDiskMark via samba och fick även där runt 50MB/s read och 170MB/s write. Sen bytte jag till VMXNET3 på alla VM och fick upp farten till 140-200MB/s och write på mellan 200-290MB/s. Dock rätt ojämna prestanda, ibland dippar det rejält under de siffrorna. NFS till Ubuntu låg riktigt dåligt på runt 70MB/s. I ZFS har jag: version=28, compression=off, dedup=off, sync=standard. NFS har jag bara satt atime=off Kanske tjänar på att ändra NFS properties? Så här ser det ut idag: NFS properties: sharectl get nfs servers=16 lockd_listen_backlog=32 lockd_servers=20 lockd_retransmit_timeout=5 grace_period=90 server_versmin=2 server_versmax=4 client_versmin=2 client_versmax=4 server_delegation=on nfsmapid_domain= max_connections=-1 protocol=ALL listen_backlog=32 device= Efter lite mer testande med tcp värden i OI fick jag till slut upp farten via nfs till ubuntu till mellan ~120-180MB/s. Har gjort följande ändringar: set tcp:tcp_conn_hash_size=32768 set ncsize=1024000 set ufs_ninode=1024000 set nfs:nfs4_bsize=1024000 set ndd:tcp_recv_hiwat=1024000 set ndd:tcp_xmit_hiwat=1024000 set ndd:tcp_max_buf=16777216 set ndd:tcp_cwnd_max=16777216 set ndd:tcp_conn_req_max_q=1024 set ndd:tcp_conn_req_max_q0=4096 Någon som har tips på att optimera mer? Särskilt NFS. |
|
| 2012-05-08, 23:15 | #4 |
EndosavianMedlem 
Plats: Linköping Registrerad: sep 2004 |
Jumbo frames på vSwitcharna?
|
|
|
| 2012-05-09, 05:26 | #5 |
ZyntaXMedlem Plats: X Registrerad: aug 2003 |
Jag kör mtu 9000 rakt igenom.
Körde en bonnie++ i linux på nfs mount nyss. Seq read: 268,4MB/s Sed write: 77,5MB/s (rewrite 58MB/s). Känner inte för att köpa en SSD til ZIL för att komma upp i ens gigabit hastihet på write över nfs. Stänga av sync känns inte heller som något alternativ. Blir nog att skrota ZFS. |
|
|
| 2012-05-09, 07:18 | #6 |
ronnylovMedlem 
Plats: Borås Registrerad: okt 2002 |
Gigabithastighet är teoretiskt maximalt 119 MB/s så jag fattar inte ens hur du lyckas komma över detta på trådat gigabit? Men det kanske är virtuella nätverk så det går kanske aldrig över några riktiga nätverkskablar.
I praktiken brukar jag nöja mig med 60 MB/s eller bättre på gigabitnätverk. Har väl kommit upp i sisådär 112 MB/s som max via samba om man kör små filer som redan är i serverns filcache. För vi pratar väl MegaByte per sekund (MB/s) och inte megabit per sekund (Mbit/s)? Testa kopiera en fil på 1 gigabyte. Tar det längre tid än 20 sekunder då kan man börja fundera på optimeringar. Tar det kortare tid än 15 sekunder då är det ganska snabbt. Går det under 10 sekunder då maxar man gigabitnätet.
__________________
Min hemsida: ronnylov.se |
|
|
| 2012-05-09, 07:37 | #8 |
ZyntaXMedlem Plats: X Registrerad: aug 2003 |
Det är en ESXi all-in-one lösning. De virtuella nicarna är 10gbit (vmxnet3) och VMCI är aktiverat.
Den enda trafik jag har utanför ESXi hosten (som går trådat gigabit) är till XBMC och där har jag däremot inget prestanda krav. Jag har siffror på benchmarks och filkopierings test i tråden redan. Och jag nöjer mig såklart inte med 50MB/s mellan VMs. Hur presterar write över NFS för er andra som kör ZFS och ESXi? Svårt att tänka mig att folk nöjer sig med ~70MB/s write på en setup som klarar ~800MB/s lokalt. |
|
|
| 2012-05-09, 07:53 | #10 |
ronnylovMedlem
Plats: Borås Registrerad: okt 2002 |
Då missförstod jag detta: "Sen valde jag att dela ut till VMs och på trådat gigabit nätverk med NFS."
Jag trodde det var NFS över trådat gigabit du ville optimera? Såg heller inget i tråden att du testat vanliga filöverföringar, bara en massa benchmarkprogram. Som jag fattat det kan benchmarks ge konstiga värden inuti virtuella maskiner. Bättre testa verklig prestanda med tidtagarur typ. Testat dela ut virtuella diskar med iSCSI till VMs istället för NFS?
__________________
Min hemsida: ronnylov.se |
|
|
| 2012-05-09, 07:54 | #11 |
ZyntaXMedlem Plats: X Registrerad: aug 2003 |
Det "ska" inte spela någon roll. Jag kan köra E1000 vnicar också. Tack vare vmci ska de prata med varandra direkt.
Men jag hittar inte hur man ändrar vswitch hastighet. Jag är tämligen nybörjare med ESXi så jag kanske missar hur du menar Jonas? Tips mottages som sagt gärna. |
|
|
| 2012-05-09, 08:05 | #12 |
ZyntaXMedlem Plats: X Registrerad: aug 2003 |
Vitek: ZFS? Verkar vara problem att få upp write hastighet allmänt med ZFS och NFS. Jag får testa med iscsi imorgon.
ronnylov: Skrev som en drummel där så förstår att det var oklart. Men jodå självklart har jag kopierat data och mätt via time. Får ut allt mellan 50-80MB/s i write. Read ligger runt 180MB/s som bäst, mer write ger inte SSDn via Sata-II som jag skriver till då. Inte testat ISCSI än då jag vill dela ut både till Windows, OSX och linux maskiner samtidigt. Men får testa ändå. Verkar vara jäkligt vanligt problem detta efter lite googling. |
|
|
| 2012-05-09, 08:42 | #13 |
vitekMedlem Registrerad: jul 2005 |
Citat:
Ursprungligen inskrivet av ZyntaX
Skickades från m.sweclockers.com |
|
|
| 2012-05-09, 10:11 | #14 |
linuxprofessorMedlem 
Plats: Kalmar Registrerad: jan 2011 |
Citat:
Ursprungligen inskrivet av vitek
__________________
Arbetsstation: Macbook Pro Retina 15", Core i7 2,6 GHz, 16 GB RAM, 512 GB SSD NAS: Synology 1812+ har numera ersatt min filserver Blog: http://www.nickebo.net/ Twitter: @linuxprofessor Övrigt: Linux/UNIX/OpenVMS, ZFS, lagring och systemövervakning |
|
|
| 2012-05-09, 15:01 | #16 |
linuxprofessorMedlem
Plats: Kalmar Registrerad: jan 2011 |
Citat:
Ursprungligen inskrivet av vitek
__________________
Arbetsstation: Macbook Pro Retina 15", Core i7 2,6 GHz, 16 GB RAM, 512 GB SSD NAS: Synology 1812+ har numera ersatt min filserver Blog: http://www.nickebo.net/ Twitter: @linuxprofessor Övrigt: Linux/UNIX/OpenVMS, ZFS, lagring och systemövervakning |
|
|
| 2012-05-09, 15:55 | #17 |
vitekMedlem Registrerad: jul 2005 |
Citat:
Ursprungligen inskrivet av linuxprofessor
Skickades från m.sweclockers.com |
|
|
| 2012-05-09, 16:15 | #18 |
linuxprofessorMedlem
Plats: Kalmar Registrerad: jan 2011 |
Citat:
Ursprungligen inskrivet av vitek
__________________
Arbetsstation: Macbook Pro Retina 15", Core i7 2,6 GHz, 16 GB RAM, 512 GB SSD NAS: Synology 1812+ har numera ersatt min filserver Blog: http://www.nickebo.net/ Twitter: @linuxprofessor Övrigt: Linux/UNIX/OpenVMS, ZFS, lagring och systemövervakning |
|
|
| 2012-05-09, 22:00 | #19 |
TalarionMedlem Plats: Helsingborg Registrerad: okt 2002 |
När vi kör mot större lagringslösningar så får vi sequential writes emot ett san med nas huvud (1Gbit) som kör nfs ~80MB/s när det gäller NFS. Random realworld test (iometer) 22MB/s. Då pratar vi om ~15-20 SAS diskar. Det är ju så att vmware alltid mountar med sync writes det sänker hastigheten då den måste får svar på att writes commitats till disk så det är mycket kontrolldata som skickas på länken. Det jag märkt är att vid sequential så presterar i princip alltid iscsi bättre i dessa fallen (maxar 1Gbit) men man tappar flexibilitet att man behöver flera datastores. Något vi har gjort tidigare är att mountat filsystemen uncached ifrån nas huvudena. En fråga varför kör du inte RDM's ifrån din raid kontroller istället för att dela ut det ifrån en virtuell maskin? Låt servern hantera all disk om du ändå bara kör allt i en box då du köpt en riktig kontroller.
__________________
Vad vore världen utan silvertejp? |
|
|
| 2012-05-10, 04:01 | #20 |
ZyntaXMedlem Plats: X Registrerad: aug 2003 |
ISCSI ska prestera bättre än NFS i ESXi helt klart pga sync writes, utanför ESXi så är det kanske en annan femma.
Nu är det inte prestanda till ESXi hosten utan direkt mellan VMs. Jag satt atime=off i filsystemet och monterar nfs med noatime eller relatime. Tjänar väl lite på det iaf. Angående kontrollern så är det en billig kontroller utan cache och bbu men SAS2. HBA kort flashat med IT firmware så raid funktioner används inte alls, men passar ypperligt till ZFS. ZFS med 16gb ram och hyfsade prestanda trodde jag skulle prestera i klass med en hårdvaruraid och ändå ha nytta av ett bra filsystem. Jag trodde att ett system som orkar skyffla data snabbt internt skulle orka mer än 70-80mb/s via NFS. Måste fundera ifall man ska satsa på att försöka få upp farten med ZIL och L2ARC eller kliva över på annan lösning. Min tidigare mdadm raid-5 på 4 mkt slöare diskar överpresterade denna lösning över NFS konstigt nog. |
|
|
| 2012-05-10, 07:11 | #21 |
ronnylovMedlem
Plats: Borås Registrerad: okt 2002 |
Raidz ger väl inte bättre I/O än en singeldisk. Däremot ska sekventiella hastigheterna bli bra. Känns som att mirrors vore bättre. Kanske en pool bestående av två stycken eller flera mirrors så blir det ungefär som raid10.
Jag kör ZFS med freebsd på min filserver. Där kan man tweaka zfs parametrarna något. Jag kör i och för sig mest samba men det var någon av parametrarna som gjorde stor skillnad och det hade något att göra med hur ofta ZFS gjorde commits mot diskarna. Prestandan var liksom lite ryckig eller pumpande, skyfflade lite på nätverket, skyfflade lite mot diskarna, sedan nätverket igen och så vidare. Genom atrt justera någon parameter så kunde man få det att flyta bättre. Nu kör ju du openindiana så det är väl inte säkert man kan göra samma tweaks. Kolla med shcrimp här på forumet, han och jag hade lite diskussioner om filservertweakande i hans tråd om filserver på freebsd. Jag minns inte själv riktigt vad vi kom fram till men jag har för mig han också hade problem med NFS och ZFS. Här är tråden: http://www.sweclockers.com/forum/17-...d-freebsd-zfs/ Jag hittade tweaket som gjorde skillnad: http://www.sweclockers.com/forum/17-...-post10381683/
__________________
Min hemsida: ronnylov.se |
|
|
| 2012-05-10, 10:02 | #22 |
ZyntaXMedlem Plats: X Registrerad: aug 2003 |
Ja precis I/O är ju lidande men sekventiellt tycker man det ska orka mer.
Ja jag har läst massor av trådar och de mesta tweaks är för BSD. Jag ska söka efter motsvarighet till Solaris/Openindiana. Jag har gjort en del tcp tweaks som gjort skillnad. Pinsamt nog så har jag inte haft compression påslaget i ZFS, läste att det kunde öka prestanda även över NFS. Inte nämnvärt overhead, bättre prestanda och man sparar plats. Win/win. Förstår inte varför jag inte slog på det när jag skapade poolen. Gammalt tänk att kompression är dåligt antar jag. Nu helt plötsligt fick jag bättre siffror. admin@ubuntu-vm:/media/download/test$ dd if=/dev/zero of=/media/lagring/test/test.000 bs=1M count=10000 10000+0 poster in 10000+0 poster ut 10485760000 byte (10 GB) kopierade, 39,4796 s, 266 MB/s bonnie++ gav också 250MB/s write och 270MB/s read. Nu börjar det likna något 
|
|
|
| 2012-05-10, 10:40 | #23 |
ronnylovMedlem
Plats: Borås Registrerad: okt 2002 |
/dev/zero är väl bara nollor, alltså extremt lättkomprimerat? Hur blir det om du kör med "normala" filer istället?
__________________
Min hemsida: ronnylov.se |
|
|
| 2012-05-10, 12:01 | #25 |
ronnylovMedlem
Plats: Borås Registrerad: okt 2002 |
Trevligt!
__________________
Min hemsida: ronnylov.se |
|
|
| 2012-05-11, 12:48 | #27 |
ronnylovMedlem
Plats: Borås Registrerad: okt 2002 |
Du satte alltså compression=on på filsystemet? Det finns väl några olika kompressionsalgoritmer man kan testa med i ZFS för att hitta balansen mellan processoranvändning och hur hårt det komprimeras. Det vet du nog redan men jag nämner det ändå.
__________________
Min hemsida: ronnylov.se |
|
|
| 2012-05-11, 16:51 | #28 |
ZyntaXMedlem Plats: X Registrerad: aug 2003 |
Ja precis jag satte compression=on och kör lzjb komprimering. gzip kan man också köra med risken är att man får overhead då så jag kör vidare med lzjb. Sjukt hur mkt prestanda det ökade dock. Tänker tillbaka på tiden när folk slog på komprimering i Windows och sen undrade varför datorn var oanvändbar
|
|
|
| 2012-06-13, 21:11 | #29 |
mj0neMedlem Plats: kna Registrerad: dec 2007 |
Hej ZyntaX
Hur påläst är du om ZFS och lagring generellt sätt? En sak med NFS är att det är synkront, vilket betyder att NFS client kräver ett svar från servern att datan den precis skickat är skrivit till stabil lagring. Om du har massa vanliga diska och just SATA(som är halvduplex dessutom bl.a) så kommer huvuden att röra på sig mycket då den synkrona förfrågan om dataskrivningen ska ned till disk asap. Man kan slå av synkron från NFS sida och det gör man vid monteringen. Men när du sedan ska använda ZFS är det en hel del annat att tänka på. Precis som ronnylov skriver så har du aldrig mer skriv prestandard på en raid5(6)/raidz(2) än en enskilld disk. Detta på grund av pariteten som ska räknas ut... det läggs också på en pytteliten latens för detta. Mirrors är inte så tokigt, och ha man mycket läs så kan t.o.m en 3-vägs spegling passa bättre. Sedan har vi ZIL som jag tycker du borde använda dig av, speciellt om du ska köra NFS. När data kommer in till en maskin med ZFS så finns det en inställning som säger hur länge datat ska hållas i minne OCH skrivas mot en ZIL disken om det skulle hända något. Efter 5-10 sekunder beroende på vad inställningen är så skrivs datan ned fint på underliggande VDEVs i en seq överförning. Snygg och fint. När datan är skriven så ogiltlighets förklaras datan på ZIL disken. Alltså, man skriver enbart mot denna disk, utom om stömmen har gått, då läser man upp datan och skriver ned den snygg och fint. En ZIL disk ska därför vara så LÅG i latens det bara går(för att få snabba svar tillbaka), men samtidigt om det är en SSD(vanligtvis) så är det SLC som gäller just för att man skriver hela tiden. För L2ARCH så är det bara att slänga in MLC diskar och matcha sitt "working set" (den datan som används typiskt mycket). Måste mätas med tiden då cacharna ARCH och L2ARCH måste bli värma. När det kommer till ZFS, så fläska på med minne När du utför tester är det viktigt vilken typ av I/O du lastar, random eller seq. Och sedan om det är synkront eller asynkront. Värt att notera är att VMware skriver alltid synkront, och tack vare de stora antalet VMs man kan köra så blir lasten väldigt random. Edit: sen har ju vilken blocksize stor betydelse på ren I/O och bandbredd du kan få ut. Låt oss säga att man har små block på 16K och man har 2000 IO/sec på diskarna så blir det typish 32 MB/s, om du där emot har 128K block men fortfarande 2000 IO/sec så blir det 256 MB/s. Edit2: VMware och NFSv3 funkar bäst. Edit3: Vet inte varför du har satt igång VMCI, man får inte bättre nätverks prestandard och det är ett API som applikationer i gäst OS måste ha stöd för. Se länken: http://communities.vmware.com/thread/206501 Senast redigerad av mj0ne 2012-06-13 klockan 21:42. |
|
|
| 2012-06-14, 11:22 | #30 |
saddamMedlem Plats: Sthlm Registrerad: nov 2008 |
Här skriver ju Linuxprofessor att ZIL höjer prestandan för NFS. Precis det du upplever?
http://www.nickebo.net/tag/zil/ (Sen undrar jag om inte en del av problemet kan bero på operativsystemet också, och inte nödvändigtvis på ZFS). |
|
|
Redaktionens senaste nyhetsrubriker
Prylar säljes, köpes, bytes och skänkes
Do you want to ask for a review, send us a press release or advertise? Don’t hesitate to contact the largest website about computer hardware in Sweden!
Vill du nå mer än 270 000 unika besökare i veckan som gillar datorer, teknik och hemelektronik? Kontakta vår mediasäljare
för mer information.
Tipsa redaktionen om en intressant produkt, önska ett test eller framför andra önskemål direkt till oss.
Copyright © 1999-2013 SweClockers AB. Allt innehåll tillhör SweClockers AB.
Citering är tillåten om källan anges. Vi reserverar oss för eventuella informationsfel.
Linjär visning
