Kopiergeschwindigkeit

Thomas Laubrock log-owl at laubrock.de
Fri Jan 3 15:15:26 CET 2014


Hallo Hajo,

Dir und allen Mitlesern auch erst mal alles Gute zum neuen Jahr.
mein erster Tip wäre, dass Deiner Kopiervarianten die Jumbofames nicht 
richtig ausnutzen.

Ich würde mal einen dumps mitlaufen lassen und mir die reale Paketgrößen 
anschauen.
Und ich würde schauen, was der TCP so sagt. Also ob hier zwischendurch 
die Windowsize runter (auf Null) geregelt wird, dass würde bedeuten, 
dass der Netzwerkstack die Packet die Ankommen nicht schnell genug 
verarbeiten kann. Wireshark erstellt da hübsche Statistiken.

Ich könnte mir gut vorstellen, dass nc einfach die 1024 Blöcke, die vom 
dd kommen auf die Reise schickt.
Also selbst die 1500 Byte gar nicht ausnutzt.

Hast Du einen rsyncd laufen oder nutzt du rsh oder gar ssh. Letztere 
Varianten bringen weiteren Overhead mit sich.

Bei solchen Tests hatte ich die beste Performance mit NFSv3 TCP und ihr 
werdet es kaum glauben AFS.

Ach ja und spannend wäre auch erst mal die Daten auf den Systemen nach 
/dev/null zu kopieren, damit Du sehen kannst, wie schnell sie überhaupt 
gelesen werden dürfen.

An den systemen selber würde ich mal schauen, welcher Prozess auf IO 
wartet, dann kannst Du sehen, ob es sender oder Empfänger ist.

Und dann kann Dir der Hypervisor noch ins essen spucken. Wenn Dir der 
Kollege nur bestimmte Ressourcen zugeteilt hat, dann deckelt der die 
Performance.

Das mal als erste Ansatzpunkte.

Gruß
  Thomas



Am 03.01.14 14:43, schrieb Hans-Joachim Hötger:
> Hallo,
> ich habe ein neues SAN Array am Start. Gerade ist wenig los, deshalb
> teste ich etwas auf dem Array herum (3PAR 7400 4controller 50T SAS in
> 450G Platten mit 10krpm)
>
> Mein Virtualisierungskollege hat mir vier virtuelle Server auf seinem
> ESX Hypervisor zum testen gebastelt. Wenn ich die Dateien mit nc
> kopiere, kommt dabei nur etwa 10Prozent des Durchsatzes heraus, den ich
> mit rsync erhalte. Das hatte ich so nicht erwartet. Kann das jemand
> erklären? Der Durchsatz ist weit von den mit iozone ermittelten
> Maximalwerten entfernt. Für große Blöcke gibt iozone etwa 400MByte/s und
> 3500IOPs aus. Alle Volumes sind mit -o sync mounted, das Netz macht
> Jumboframes.
>
> root at template_RH data]# time dd if=testfile | nc 192.168.1.12 30303
> 16777216+0 Datensätze ein
> 16777216+0 Datensätze aus
> 8589934592 Bytes (8,6 GB) kopiert, 1764,48 s, 4,9 MB/s
>
> real    29m24.544s
> user    0m10.216s
> sys     1m0.368s
> [root at template_RH data]# time dd bs=4096 if=testfile | nc 192.168.1.12 30303
> 2097152+0 Datensätze ein
> 2097152+0 Datensätze aus
> 8589934592 Bytes (8,6 GB) kopiert, 1778,08 s, 4,8 MB/s
>
> real    29m38.157s
> user    0m1.895s
> sys     0m28.382s
> [root at template_RH data]# time dd bs=8192 if=testfile | nc 192.168.1.12 30303
> 1048576+0 Datensätze ein
> 1048576+0 Datensätze aus
> 8589934592 Bytes (8,6 GB) kopiert, 1747,32 s, 4,9 MB/s
>
> real    29m7.434s
> user    0m1.332s
> sys     0m28.495s
> [root at template_RH data]# ssh 192.168.1.12 rm /data/testfile
> [root at template_RH data]# time rsync -va testfile 192.168.1.12:/data/
> sending incremental file list
> testfile
>
> sent 8590983242 bytes  received 31 bytes  49515753.73 bytes/sec
> total size is 8589934592  speedup is 1.00
>
> real    2m53.821s
> user    1m47.457s
> sys     0m44.522s
> [root at template_RH data]# tracepath 192.168.1.12
>   1:  192.168.1.10 (192.168.1.10)                            0.098ms pmtu
> 9000
>   1:  192.168.1.12 (192.168.1.12)                            0.380ms reached
>   1:  192.168.1.12 (192.168.1.12)                            0.195ms reached
>       Resume: pmtu 9000 hops 1 back 64
> [root at template_RH data]#
>
> (Just curious)
>
> Bei der Gelegenheit: Ich wünsche jedem ein frohes neues Jahr, der bis
> hierher gekommen ist. ;-)




More information about the Linux mailing list