Samba performance issue

[Ludo]

Sliter litt med hastighet med Samba på filserveren min. Vet ikke helt hva det kommer av, har hatt andre installasjoner med Samba som har fungert fint, men denne gangen sliter jeg litt.

Klientmaskinene er alle med Windows 7 Enterprise, Samba kjøres på en maskin med følgende spec:
AMD Phenom X6 1100T CPU 3,3GHz
Gigabyte GA-890FXA-UD5 med AMD890FX+SB850 chipset.
16GB RAM DDR3
6 x WD 2TB Black Edition @ RAID10 med mdadm.

Ubuntu Server 10.10 x64

Jeg bruker onboard nettverkskort, type Realtek RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03). Jeg har også testet med Intel Pro 1000 GT, men dette hjalp ikke. Jeg har også sjekket alle kabler, switcher osv; alt er i skjønneste orden samt at jeg får samme resultat med krysset kabel rett i server.

Ved kopiering mellom maskinene får jeg en hastighet som starter på 60MB/sec og som sakte dropper nedover til bare 30MB/sec og noen ganger under det også. Det samme gjelder lesehastighet, det hele går utrolig tregt.


Jeg har sjekket nettverkskapasiteten med iperf, den gir følgende output:

root@storage01:/# iperf -c 10.0.0.100 -i 3 -t 20 -w 256k
------------------------------------------------------------
Client connecting to 10.0.0.100, TCP port 5001
TCP window size: 256 KByte (WARNING: requested 256 KByte)
------------------------------------------------------------
[ 3] local 10.0.0.2 port 34892 connected with 10.0.0.100 port 5001
[ ID] Interval   Transfer  Bandwidth
[ 3] 0.0- 3.0 sec  293 MBytes  820 Mbits/sec
[ 3] 3.0- 6.0 sec  294 MBytes  823 Mbits/sec
[ 3] 6.0- 9.0 sec  295 MBytes  824 Mbits/sec
[ 3] 9.0-12.0 sec  297 MBytes  831 Mbits/sec
[ 3] 12.0-15.0 sec  294 MBytes  821 Mbits/sec
[ 3] 15.0-18.0 sec  295 MBytes  824 Mbits/sec
[ 3] 0.0-20.0 sec 1.92 GBytes  825 Mbits/sec
root@storage01:/#

I smb.conf har jeg prøvd meg frem med flere forskjellige varianter av 'socket options' uten av dette påvirker resultatet i nevneverdig positiv retning.



Er det noen av dere som har tips til hvordan man kan løse dette?

 

[nb]

Har du sjekket hvilken hastighet du får ved FTP mellom maskinene?

 

[Ludo]

Har du sjekket hvilken hastighet du får ved FTP mellom maskinene?

Jupp, det burde jeg har informert om!

Her: Transferred 1 File (4,55 GB) in 1 minute 37 second (48,13 MB/s)

Den starter på 68MB/s og dropper noen ganger til 35MB/s...

 

[Ludo]

Kan det være filsystemet som er problemet her? Jeg bruker EXT4, kanskje jeg skulle bytte til enten XFS eller JFS...

 

[nb]

Jeg er ingen ekspert, får vente til marsboer oppdager denne tråden... jeg får ganske mye større hastighet med FTP enn med vanlig filkopiering i Windows uten at jeg helt vet hvorfor (eller har brytt meg veldig mye med å finne ut hvorfor) var derfor jeg spurte.

Har du sett på hvilken hastighet du får om du kopierer lokalt på serveren din, dvs sjekket hva skriveytelsen til RAID-arrayet ditt faktisk er?

 

[Ludo]

Enig med deg, tror nok at Marsboer har flere synspunkter her

Ang lese/skriveytelse så får jeg følgende når jeg kopierer til RAID-arrayet fra en lokal disk:

73MB/sec, dette kan stemme overens med den disken jeg kopierer fra som gir følgende output på lesing:

---
root@storage01:/# hdparm -t /dev/sdg
/dev/sdg:
Timing buffered disk reads: 232 MB in 3.02 seconds = 76.89 MB/sec
---

Ren skriveytelse til /dev/md0 er:

---
root@storage01:/# dd if=/dev/zero of=/raid10/blankimage bs=4k count=2000000
2000000+0 records in
2000000+0 records out
8192000000 bytes (8.2 GB) copied, 18.1242 s, 452 MB/s
---

Leseytelse til /dev/md0 er:

---
root@storage01:/# dd if=/raid10/blankimage of=/dev/null bs=4k count=20000000
2000000+0 records in
2000000+0 records out
8192000000 bytes (8.2 GB) copied, 4.11081 s, 2.0 GB/s
---

 

[nb]

De tallene kan umulig stemme - ytelsen til snurredisker er ikke 452 MB/sek eller 2.0 GB/sek. En SSD-disk klarer kommer jo ikke i nærheten av de ytelsene der. Eller er det nor jeg har misforstått med ytelsen du måler.

 

[Ludo]

RAID10!

Merk at første lesetest ble feil siden serveren har 16GB RAM når jeg testet med 4GB data. Jeg testet derfor med en 32GB fil og fikk følgende resultat:

Skriveytelse:

---
root@storage01:/# dd if=/dev/zero of=/raid10/blankimage bs=4k count=8000000
8000000+0 records in
8000000+0 records out
32768000000 bytes (33 GB) copied, 73.1596 s, [b]448 MB/s[/b]
---

Leseytelse:

---
root@storage01:/# dd if=/raid10/blankimage of=/dev/null bs=4k count=8000000
8000000+0 records in
8000000+0 records out
32768000000 bytes (33 GB) copied, 67.0507 s, [b]489 MB/s[/b]
---

 

[Class]

Vet ikke helt hva det kommer av, har hatt andre installasjoner med Samba som har fungert fint, men denne gangen sliter jeg litt.

Har du hatt bedre ytelse med en 32bit distro før? Jeg har ikke testet siste Ubuntu 64bit server men det var alltid et eller annet rask som ikke virket helt som det skulle i 64bit i de eldre versjonene.

Er firewall av eller på på serveren? Hva med SELinux?
Har du sett på loggene til Samba?

Ellers ville jeg ikke brukt noe Realtek om jeg fikk betalt for det men du sier at Intel Pro GT kortet ikke gjorde noe forskjell.

 

[marsboer]

Serveren din virker OK, selv om båndbreddene dd gir nok ikke er helt realistiske siden RAID10 med 6 disker maksimalt kan gi en skriveytelse tilsvarende 3 disker i RAID0. Kjører du RAID10 med far layout kan du imidlertid regne med en leseytelse nesten tilsvarende alle 6 diskene i RAID10. Default er near som gir en lesehastighet tilsvarende 3 disker. Det kan se ut som om det er det du kjører hos deg.

820mbit/s er imidlertid unormalt dårlig på iperf. Du burde ligge rundt 935mbit/s. I hvertfall godt over 900. Var det noen annen aktivitet da du kjørte testen?

Uansett er det slik at out-of-the-box ytelse på samba på Debian 64-bit som jo ubuntu er basert på gir det remmer og tøy kan holde. Man skal ikke behøve å tweake noe utover default oppsettet for maksimal hastighet. Med andre ord rundt 112MB/s eller maksimal utnyttelse av gigabit (med protokolloverhead). Oppnår du ikke denne hastigheten er det nærmest garantert disksystemene i den ene eller andre enden som ikke holder følge (bortsett fra at nettverket ditt ikke virker helt OK med bare 820mbit/s på gigabit). FTP-ytelsen underbygger også det faktum at samba ikke er problemet her siden disse båndbreddene matcher hverandre godt (FTP skal yte noen få MB bedre enn Samba).

Jeg har imidlertid merket meg at samba er meget tregt om klienten kjører Linux (rundt 10MB/s). Jeg har derfor satt opp NFS for Linux-maskinene.

60-30MB/s (480-240Mbit/s) høres helt normalt ut om det f.eks kun er en enkelt disk i den ene involverte maskina eller det er snakk om noe annet enn sekvensielle data. Serveren kjører RAID10 med seks disker, men hva slags disksystem kjører den andre parten?

 

[marsboer]

Her er et normalt resultat med iperf (out-of-box ytelse):

server (Debian 6.0 64bit):

root@merkur:~# iperf -s -w 256k

klient (Ubuntu 10.10 Desktop 64bit):

root@hi-fi:~# iperf -c 10.0.0.1 -i 3 -t 15 -w 256k
------------------------------------------------------------
Client connecting to 10.0.0.1, TCP port 5001
TCP window size: 256 KByte (WARNING: requested 256 KByte)
------------------------------------------------------------
[ 3] local 10.0.0.34 port 47611 connected with 10.0.0.1 port 5001
[ ID] Interval   Transfer  Bandwidth
[ 3] 0.0- 3.0 sec  337 MBytes  941 Mbits/sec
[ 3] 3.0- 6.0 sec  337 MBytes  941 Mbits/sec
[ 3] 6.0- 9.0 sec  337 MBytes  941 Mbits/sec
[ 3] 9.0-12.0 sec  337 MBytes  941 Mbits/sec
[ 3] 12.0-15.0 sec  337 MBytes  941 Mbits/sec
[ 3] 0.0-15.0 sec 1.64 GBytes  941 Mbits/sec

EDIT:
Legger til at Debian serveren har et Intel server NIC integrert og benytter e1000e driveren i kernelen, mens Ubuntu-maskinen kun benytter det integrerte Realtek-kortet med kernelens RTL8168b/8111b driver

 

[Ludo]

Sånn, da har jeg fått orden på iperf:

root@storage01:~# iperf -c 10.0.0.100 -i 3 -t 20 -w 256k
------------------------------------------------------------
Client connecting to 10.0.0.100, TCP port 5001
TCP window size: 256 KByte (WARNING: requested 256 KByte)
------------------------------------------------------------
[ 3] local 10.0.0.2 port 33454 connected with 10.0.0.100 port 5001
[ ID] Interval   Transfer  Bandwidth
[ 3] 0.0- 3.0 sec  335 MBytes  937 Mbits/sec
[ 3] 3.0- 6.0 sec  335 MBytes  937 Mbits/sec
[ 3] 6.0- 9.0 sec  334 MBytes  934 Mbits/sec
[ 3] 9.0-12.0 sec  335 MBytes  938 Mbits/sec
[ 3] 12.0-15.0 sec  335 MBytes  937 Mbits/sec
[ 3] 15.0-18.0 sec  334 MBytes  934 Mbits/sec
[ 3] 0.0-20.0 sec 2.18 GBytes  936 Mbits/sec

Hastighet på kopiering fra Windowsklient til server går fortsatt like tregt da, starter på samme hastighet som før og faller sakte nedover... Hmm...

 

[marsboer]

Ved kopiering til serveren vil du normalt se at datastrømmen initielt begrenses kun av lesehastighet på Windows-klientens harddisk. De første dataene caches nemlig i RAM på serveren. Etterhvert som RAM-cachen fylles opp vil man se mer og mer den reelle hastigheten på mediet.

Kan du si noe om diskløsningen på Windows 7 klienten og hva slags data du sender over når du opplever hastigheter fra 30-60MB/s? Husk å ikke forveksl MB/s med Mbit/s forøvrig. 60MB/s er trossalt 50% utnyttelse av gigabitlinken og det er ikke realistisk å opprettholde denne hastigheten på noe annet enn helt sekvensielle data med mindre disksystemene det leses fra og til er meget raske.

 

[Ludo]

Jeg har en PC med Windows 7 x64, Intel Core i7 930 @3,66GHz, 24GB RAM og Crucial RealSSD C300 2,5" 256GB, SATA 6 Gb/s, (opp til 355MB/215MB sec lese/skrive) så jeg tror ikke det er det som er flaskehalsen. Takk for tipset likevel


Edit: korrigert disktype

 

[marsboer]

Joda, en enkelt Corsair 256GB SSD SATA-III er ikke nok for å ligge på 110MB/s flatt til tross for at den klarer mer enn dette i tester. Jeg har selv en Intel X25 gen. 2 160GB disk og denne klarte sjelden å komme over 100MB/s kontinuerlig og lå vanligvis nærmere 90MB/s over lengre tid gitt optimale data. Nå har jeg imidlertid en OCZ revodrive 180GB som i praksis er to SSD-disker i RAID0 tilkoblet PCI-e x4 grensesnittet. Dette kortet leverer 500MB/s les og skriv i best case scenarioer og leverer maksimal gigabithastighet gitt optimale data. Men gitt mer tilfeldige småfiler klarer ikke dette kortet å kjøre på maksimalt det heller.
100+MB/s hastigheter på absolutt alle filscenarioer (små filer, bilder musikk, dokumenter, film osv) har jeg kun opplevd når jeg overførte mellom filserverne mine når begge kjørte 8xdisker i RAID6, og da ikke over samba, men rsync.

Årsaken til at det fremdeles kan være disken din som er flaskehalsen kan være flere. Det virker på meg som om dette er samme disk som du kjører OSet på. Med andre ord må disken hele tiden avbryte overføringsoperasjonen for å gjøre OS-ting. Om du ser på PCen din når den idler vil disklampen blinke regelmessig, rett og slett fordi det alltid pågår en form for diskaktivitet i systemet. Når systemet idler er det vanligvis logger som skriver til disk.
Kjører du kildedisken som en tilleggsdisk med OS på egen disk vil hastigheten sannsynligvis øke.

I tillegg har du sannsynligvis en form for antivirusløsning kjørende som scanner fildata når filer overføres.

Det kan også være at firmwaren på SSD-disken din ikke jobber optimal med den typen datastrømmer du påtrykker når du tester.

Skal du makse gigabiten på generell basis trenger du i dag en form for hurtig flerdisks RAID-løsning i begge ender (jeg kjører jo i praksis RAID0 med SSD). 30MB/s er likevel noe tregt. Siden trafikken starter på 60MB/s og gradvis reduseres når minnecachen fylles på filserveren er det naturlig å anta at det er skrivehastigheten på filserveren som da ender opp rundt 30MB/s. RAID10 med bare seks disker er ikke noe lynhurtige greier på skriving, men dette var likevel dårlig i forhold til hva jeg har opplevd i tester hjemme med Debian 64-bit. Det har jo skjedd før at Ubuntu ikke leverer samme robusthet som Debian på serversiden, men det er jo litt rart likevel.

En alternativ problemstilling:
Kan det være mulig at du faktisk ikke jobber mot md0-RAIDet i samba-sharet? Det vil si at mappen er korrekt henvist til i samba-innstillengene, men at md0 RAIDet faktisk ikke er mountet i mappen. Med andre ord jobbes det i praksis mot OS-disken i Linux-serveren.

 

[Ludo]

For å svare på det siste først:

root@storage01:~# df -H
Filesystem       Size  Used Avail Use% Mounted on
/dev/sdg1       473G  22G  428G  5% /
none          8.4G  275k  8.4G  1% /dev
none          8.5G   0  8.5G  0% /dev/shm
none          8.5G  369k  8.5G  1% /var/run
none          8.5G   0  8.5G  0% /var/lock
/dev/md0        6.0T  33G  5.6T  1% /raid10

/dev/md0 er mountet på /raid10 og den er også delt ut via smb.conf slik:

[raid10]
    comment = first raidstorage from storage01
    path = /raid10
    browseable = yes
    read only = no
    guest ok = yes
    guest account = nobody
    guest only = yes

 

[Ludo]

Merk at disken er en Crucial RealSSD C300 2,5" 256GB, SATA 6 Gb/s, opp til 355MB/215MB sec lese/skrive. Det var feil at det var Crucial, har jo ikke oversikt over hardware en gang

Jeg har jo lett fått 90MB/sec tidligere og mer enn det også så jeg skjønner ikke hva som er forskjellen nå, alt jeg har er jo raskere enn det forrige oppsettet.
Når jeg kopierer internt på arbeidsstasjonen går det kjapt unna, og når jeg kopierer en stor fil (32GB) fra serveren til arbeidsstasjonen så ligger den på 77MB/sec...

Når det gjelder det kopiering til server så kopieres det fra flere kilder, SSD-disken og flere andre også. Hastigheten er den samme.

Er vel litt rådvill her nå, kan trygt si at jeg famler rundt i blinde

Kan aktivering av jumboframes ha noe med dette å gjøre?

 

[Ludo]

Til info så overfører jeg med ca 75MB/sec via FTP-protokollen fra klient til server... Og det er jo litt forskjell det, den er også stabil på den hastigheten.

Transferred 1 File (2,24 GB) in 30,49 seconds (75,18 MB/s)

 

[marsboer]

Til info så overfører jeg med ca 75MB/sec via FTP-protokollen fra klient til server... Og det er jo litt forskjell det, den er også stabil på den hastigheten.

Transferred 1 File (2,24 GB) in 30,49 seconds (75,18 MB/s)

Den er kun stabil på den hastigheten fordi du kopierer mindre data enn RAM-cache på serveren. Med andre ord er prosessen i praksis: Les fra SSD -> gigabit -> RAM på server
Du bør oppnå nesten tilsvarende hastigheter med samba på den samme lille filen (2,24GB) (rundt 70MB/s)
Uansett er jo ikke dette så bra det burde ha vært. Lesing sekvensielt fra en så rask SSD burde makset gigabiten i begynnelsen inntil RAM-cachen på serveren fylles.

Hvis du ikke gjør det er det ting som tyder på at det er noe som ikke er helt optimalt. Siden Debian alltid har gitt hardwaremessig forventede hastigheter på Samba her hjemme så kan jeg dessverre ikke komme med noen gode tips angående Ubuntu Server. Ubuntu Desktop som CIFS-klient er imidlertid svært tregt så det kan jo faktisk hende at Ubuntu har gjort noe grums med cifs-protokollimplementasjonen sin.
Jeg tror hovedsaklig at problemet ligger på Windows-maskina siden Ubuntu er såpass likt Debian, selv om jeg ikke har verifisert ytelsen på Ubuntu.

Siden lokal kopiering er raskt må man se på hva som er annerledes når ting kopieres over nettverket. Nettverket er OK i følge iperf, så det må være noe som skjer når det involveres filer.

 

[Ludo]

Nå har jeg kommet litt videre, har testet med kopiering av den store fila fra en Dell Latitude E6400 m/Intel 82657LM Gigabit nettverkskort og den pusher data med en fart på 115-116MB/sec og da er jeg jo der jeg skal være. Samme gjelder også for mediabox'n min, den ligger tett opptil samme hastighet. Så feilen ligger på arbeidsstasjonen og der er det noe som er galt. Skal sjekke litt rundt, evt ta en reinstall og se hvordan den oppfører seg. Har jo et Intel nettverkskort i den også, mulig det er noe galt med det evt en driver som trenger en oppdatering eller så.

Takk for alle innspill så langt

 

[marsboer]

Nå har jeg kommet litt videre, har testet med kopiering av den store fila fra en Dell Latitude E6400 m/Intel 82657LM Gigabit nettverkskort og den pusher data med en fart på 115-116MB/sec og da er jeg jo der jeg skal være. Samme gjelder også for mediabox'n min, den ligger tett opptil samme hastighet. Så feilen ligger på arbeidsstasjonen og der er det noe som er galt. Skal sjekke litt rundt, evt ta en reinstall og se hvordan den oppfører seg. Har jo et Intel nettverkskort i den også, mulig det er noe galt med det evt en driver som trenger en oppdatering eller så.

Takk for alle innspill så langt

Windows 7 (og Vista) har en tjeneste kalt Multimedia Class Scheduler som throttler ned antall pakker som kan sendes på nettverket dersom en lydavspiller er oppe (det holder at man f.eks har Media Player oppe). Dette gjør den for å sikre at lyden på trege maskiner får nok CPU-ressurser til å avspilles uten hikk selv under tung nettverksbelastning (dette fikser ikke problemer man kan få med USB-lydkort når det foregår annen USB-aktivitet på samme USB-kontroller)

I Vista fungerte denne tjenesten svært dårlig siden den hadde hardkodet antall pakker til 10000p/s dvs omlag 100mbit/s om den detekterte et lydavspillende program. Man fikk med andre ord redusert hastigheten til omlag 1/10 bare ved å avspille musikk samtidig.

I Windows 7 har jeg ikke opplevd noe problematikk med denne tjenesten og har derfor ikke slått den av. Den er kraftig forbedret i forhold til den hardkodede versjonen i Vista. Men det kan jo hende at den har fått en eller annen form for problemer, så du kan jo teste å slå av tjenesten.

 

[marsboer]

Jeg må bare komme med en oppdatering her. MMCSS-udyret er tilbake, denne gang i Windows 7!
Jeg har til nå hatt full ytelse med MMCSS påslått. Men når jeg nå jobbet med overføringer av filer reagerte jeg på den meget labre overføringshastigheten. Det eneste som var annerledes fra vanlig var at jeg hadde spotify oppe. Jeg lukket spotify og da føyk hastigheten rett opp igjen. Jeg utførte samme test med foobar. Alt er fint helt til man faktisk avspiller lyd. Men har man først gjort det er hastigheten stuck på rundt 11-14MB/s helt til man lukker lydapplikasjonen.

Det tok lengre tid enn sist å finne ut helt konkret hva som forårsaket elendigheten fordi iperf faktisk maxer gigabiten med lyd under avspilling, selv om hastigheten av og til lå på bare 880Mb/s mot normalt 945Mb/s. Det gjelder med andre ord hovedsaklig KUN for filoverføring!

Det eneste jeg kan huske har endret seg på maskina mi er SP1 og diverse hotfixer, samt IE9. Men det kan også være at jeg ikke har benyttet lyd samtidig med tung nettverksaktivitet i særlig grad i Windows 7.

Jeg tror faktisk dette er noe som har dukket opp igjen, og er kanskje maskinspesifikt.

Uansett så slo jeg av MMCSS-tjenesten. Men man må fjerne avhengigheten Windows Audio har til tjenesten, hvis ikke får man ikke lyd.
Åpne regedit -> HKEY_LOCAL_MACHINE -> System -> CurrentControlSet -> Services -> AudioSrv -> DependOnService -> fjern MMCSS fra listen og restart maskinen
Åpne services.msc -> Multimedia Class Scheduler -> trykk på Stop og velg startup type Disabled

For de som lurer på hva denne tjenesten gjør så er det å prioritere øvrig aktivitet på maskinen for å sikre god avspilling av lyd uten hakking. Tjenesten ble introdusert i Vista fordi dette OSet hadde en helt ubrukelig nettverksstack rent ressursmessig. Når jeg makset gigabiten på Vista-maskinen var CPU bruk over 40% på en Intel E8400 3GHz Core 2 Duo
standard. Om man oversetter dette til den mest ubrukelige maskinen som kan tenkes å kjøre Vista/Windows 7 så skjønner man at det fort kan bli problemer. De velger derfor å throttle nettverket i stedet for å fikse de reelle ytelsesproblemene.
Den kunstige avhengighetn audiosrv har til MMCSS kan trygt fjernes uten bivirkninger på alle moderne oppegående maskiner.
Til sammenligning benyttet samme hardware omlag 12% CPU på samme type trafikk på Debian.

 

[bambadoo]

Interessant marsboer. Har opplevd noe lignende men jeg endte opp med å resette nettverkskortet faktisk. Da ble det bedre igjen..
Men hvorfor?
Ja nå tenker jeg win7 enterprise med sp1.
Har ellers ikke hatt noen nettverks problemer til tross for foobar installert og spiller (konstant )

For 2 min siden. Med foobar vel igang ....


Varierer sånn stort sett mellom 85-115 MB (windows tellemåten )

 

[marsboer]

Jeg kan som sagt ikke huske å ha hatt dette problemet før (bortsett fra i Vista hvor dette var et problem i alle tilfeller).
Jeg oppgraderte til SP1 i går og i den forbindelse feilet prosessen så jeg måtte inn med en spesiell hotfix. I tillegg installerte jeg IE9.

Jeg mistenker derfor at dette gjelder i enkelte tilfeller og at det muligens er en bug som har oppstått nylig og trigger MMCSS der den før har holdt seg unna de verste prioriteringene.
Men det ligner veldig på det trådstarter har opplevd så jeg la det inn her.

Uansett er problemet helt forduftet nå som MMCSS er avslått. Men om dette var et symptom på at noe annet er galt, eller selve årsaken er foreløpig uvisst.

 

[bambadoo]

Når du sier det. Tror det faktisk skjedde noe problem hos meg også. Ikke ved oppgradering til sp1 men ved oppgradering til ie9. Mener det var da problemene oppsto. Har ikke "hengt" dette på noe før..... Jeg hadde ie9 beta fra før. Måtte avinnstallere denne før ie9 ferdig skulle innstalleres. I etterkant så ble det skikkelig tregt. Helt til jeg "resatte" nettverkskortet. Og alt var tilbake...
Dette er litt rart faktisk.