Trage file transfers over SMB/SFTP/HTTP/etc via gbit LAN

[geez]

Systemen: Debian 6.0.5 x64 server (specs) en Ubuntu 12.04 x64 + Windows 7 x64 client (specs).
Server: 3x Western Digital Caviar Green 1.5TB SATA, met / in raid1 en /home in raid5. Software raid met mdadm.
Netwerk: Gbit lan over CAT5e kabels van 1 en <10m en Netgear gbit switch en Linksys WRT120N die DHCP uitdeelt en internet verzorgt.

Probleem: Langzame file transfers tussen client en server. Zowel via SFTP, SMB als HTTP. SMB en HTTP halen zo'n 35-45MB/s (beide kanten op), SFTP haalt zo'n 24MB/s met de wind mee, 15MB/s bij wind tegen

RAID details:

code:

wesley@databeest:~$ cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid4] 
md1 : active raid5 sda2[0] sdc2[2] sdb2[1]
      2912102400 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]
      
md0 : active raid1 sda1[0] sdc1[2] sdb1[1]
      7815488 blocks [3/3] [UUU]
      
unused devices: <none>

SFTP test server -> client, SFTP locatie gemount op /server/ (dd van de raid5 array naar dev/null op de client):

code:

wesley@wesley-desktop:~$ dd if=/server/raid5/some/file of=/dev/null
^C1907425+0 records in
1907424+0 records out
976601088 bytes (977 MB) copied, 37.6879 s, 25.9 MB/s

LAN test met iperf, beide kanten op:

code:

wesley@wesley-desktop:~$ iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 192.168.1.4 port 5001 connected with 192.168.1.7 port 42626
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-10.0 sec  1.10 GBytes   941 Mbits/sec
^Cwesley@wesley-desktop:~$ iperf -c 192.168.1.7
------------------------------------------------------------
Client connecting to 192.168.1.7, TCP port 5001
TCP window size: 23.5 KByte (default)
------------------------------------------------------------
[  3] local 192.168.1.4 port 46044 connected with 192.168.1.7 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.10 GBytes   943 Mbits/sec

raid1 read/write:

code:

databeest:/# dd if=/dev/md0 of=/dev/null
^C1802737+0 records in
1802736+0 records out
923000832 bytes (923 MB) copied, 10.9583 s, 84.2 MB/s

databeest:/# dd if=/dev/zero of=/testfile
^C1419395+0 records in
1419395+0 records out
726730240 bytes (727 MB) copied, 11.1076 s, 65.4 MB/s

raid5 read/write:

code:

databeest:/# dd if=/dev/md1 of=/dev/null
^C3407274+0 records in
3407273+0 records out
1744523776 bytes (1.7 GB) copied, 9.55614 s, 183 MB/s

databeest:/# dd if=/dev/zero of=/home/testfile
^C1572044+0 records in
1572044+0 records out
804886528 bytes (805 MB) copied, 11.8417 s, 68.0 MB/s

Alle relevante afzonderlijke onderdelen lijken dus sneller te zijn dan de snelheden die ik daadwerkelijk behaal. Een server->client copy over SFTP resulteert in een cpu usage van gemiddeld 35-40% op 1 core van de server, dus daar lijkt de bottleneck ook niet te liggen. Bij SMB en HTTP is dit zoals verwacht lager (encryptie overhead).

Zou er een rotte schrijf tussen zitten (raid5 write lijkt me wat laag?) of is hier iets anders aan de hand?

Wat ik al geprobeerd heb:
- Met cpufreq beide cores van de server CPU op performance gezet. Bij ondemand schakelde hij te snel heen en weer, wat resulteerde in schokkerige SFTP performance.
- Bovenstaande tests vanaf desktop client.
- Laptop, SFTP+SMB op Ubuntu 12.04 en SMB op Win7, met dezelfde resultaten als hierboven. Dit tevens met een andere switch-laptop UTP kabel.

[ Voor 7% gewijzigd door geez op 27-06-2012 12:06 ]

[jackorobot]

Ligt het misschien aan mij, of vind ik dit acceptabele waardes?
Met software raid is mijn ervaring dat je niet de allerhoogste schrijfperformance krijgt, en al helemaal niet bij raid 5, dus ik vind het er redelijk acceptabel uitzien.
Je kan allicht met WDDiagnostics (test tool van WD) kijken of de schijven fouten aangeven, maar dat zal waarschijnlijk niet zo zijn.

[geez]

De raid5 write is inderdaad niet verschrikkelijk en sowieso acceptabel, maar ik wilde het toch even noemen met het oog op de prestaties over LAN, want dat is uiteindelijk het probleem.

Heb ook even extended SMART tests gestart op alle 3 de schijven met smartctl. (255 minuten)

edit: Alle SMART tests completed without error.

edit2: Getest met laptop (Ubuntu 12.04 en Win7), hetzelfde resultaat (zie boven).

Even een uitgebreidere reactie op jackorobot: Naast de schrijfperformance haal ik 190MB/s read vanaf raid5, en 940mbit =~ 117MB/s over gbit LAN. Als ik dus kopieer naar /dev/null op de client (ongelimiteerd door lokale writes dus) over SMB of HTTP (geen encryptieoverhead) verwacht ik meer dan 40MB/s te halen, zeker als CPU use daarbij heel laag is.

Nog suggesties? I'm out of ideas

[ Voor 53% gewijzigd door geez op 26-06-2012 16:29 ]

[geez]

Subtiele bump..

[geez]

Laatste bumppoging.

[Koenvh]

Wat is de kwaliteit van de ethernetkabel? Dat kan een groot verschil maken op snelheden

[geez]

CAT5e, heb er twee geprobeerd overigens i.c.m. een andere client (zie ook topicstart). Lijkt echter het probleem niet te zijn, omdat ik met iperf wel ~940mbit haal.

[ Voor 5% gewijzigd door geez op 30-06-2012 21:41 ]

[Kanarie]

Ik dacht ooit wat slimme tweaks in smb.conf gezet te hebben (socket options = ...), maar die bleken de boel alleen maar langzamer gemaakt te hebben.
Zonder die tweaks haal ik de volle 112-117MB/s tussen een Debian server en Windows 7 client. Zowel up als down.

[Thralas]

Je zou sftp nog eens kunnen proberen met scp -c arcfour

[ik222]

Hoeveel werkgeheugen heeft je server en hoeveel daarvan wordt gebruikt?

[ Voor 36% gewijzigd door ik222 op 30-06-2012 21:50 ]

[geez]

@Kanarie: Dat had ik dus ook verwacht.

@Thralas: scp met arcfour heb ik geprobeerd, met interessante resultaten.

code:

scp -c arcfour wesley@server:/een/grote/file /dev/null

80-90MB/s gemiddeld.

code:

scp wesley@server:/een/grote/file /dev/null

40-50MB/s gemiddeld.

Met arcfour haal ik dus hogere snelheden dan zelfs HTTP! Iets anders dat opvalt: Als ik htop aan heb staan tijdens deze transfers zie ik twee dingen. Arcfour maakt gebruik van beide cores, die gaan naar 60-80% beiden. Zonder arcfour wordt maar een van de twee cores gebruikt, en deze gaat naar zo'n 70-75% maar komt eigenlijk nooit boven de 80%. Dit zou het verschil in prestaties tussen de twee verklaren, maar wat ik dan niet snap:
- Waarom gaat CPU use niet naar (bijna) 100%, in beide gevallen, als de raid array de bottleneck niet is?
- Waarom zijn zowel SMB als HTTP niet sneller dan beide van deze, zeker als het CPU gebruik daar <20% is?

@ik222: Server heeft 2GB DDR2 (specs), en afhankelijk van wat hij (voornamelijk SABnzbd+) aan het doen is, gebruikt hij tot zo'n 1GB. Van de 3.63GB swap wordt eigenlijk geen gebruik gemaakt (35MB momenteel), zoals te verwachten. Swap uitzetten maakt overigens geen verschil.

[geez]

Iemand enig idee m.b.t. bovenstaande? Het is me nog niet eerder gelukt een vraag te stellen op GoT waar we niet uit kwamen..