Hallo,
sind hier evtl. ein paar Linux / Samba Spezialisten?
Folgendes Problem:
Ich habe einen kleine Fileserver der Dateien über Samba zur Verfügung
stellt. Allerdings ist der Datentransfer IMHO zu gering.
iptraf zwischen dem Fileserver und meinem Desktop zeigt ca. 700 Mbit.
Ein "cat /dev/sdb1/test.bin > /dev/null" liest Daten von der Platte mit
ca. 80MB/s. (sdb1 ist die Parition die über Samba freigegeben ist).
Ich würde also davon ausgehen, dass ich Daten (speziell große Dateien)
mit über 70 MB/s lesen kann ... praktisch erreiche ich aber nur
irgendwas um die 45 MB. (Ich habe auch mal FTP probiert, da erreiche ich
ähnliche Werte).
Der Fileserver ist an sich nicht optimal - "nur" ein alter Pentium 4,
2.6 GHz, 768 MB RAM, Centos 6.2. Ich habe schon diverse TCP/IP
Einstellungen und Samba "Tricks" aus diversen Foren probiert - wirklich
viel gebracht hat's aber nix.
Mich wunderts nur, weil ich nur 50% von dem theoretisch möglichem
erreiche ...
Hat wer ne gute Idee wo ich die Leistung verlieren könnte?
JosefDermler schrieb:> Hat wer ne gute Idee wo ich die Leistung verlieren könnte?
Nu, TCP/IP-Overhead, Protokollstack, Dateisystem, SMB1 ist ein dämliches
Protokoll...
Versuch doch vergleichsweise mal eine NFS-Freigabe.
Was liefert FTP ?
Was liefert NFS ?
Was liefert lokales lesen von Dateien ? (Nicht Partionen)
Was liefert iperf ?
Wie ist die CPU Auslastung ?
Wie ist die Window Size ?
Wie sind die Samba tuneables eingestellt ?
Wer misst misst Mist schrieb:> Was liefert FTP ?
siehe oben - mit FTP kommen ich auf ähnliche Werte. Liegen im Bereich
von 45 MB/sec
> Was liefert NFS ?
kann ich leider nicht testen - habe grad keine zweite Maschine die NFS
könnte.
> Was liefert lokales lesen von Dateien ? (Nicht Partionen)
siehe oben - beim Lesen von Dateien komme ich auf ca. 80 MB/sec
> Was liefert iperf ?
siehe oben - ca. 700 Mbit
> Wie ist die CPU Auslastung ?
Kopiere ich über die Samba-Freigabe, sagt mir vmstat das hier:
procs ---------memory---------- -swap-- -----io-- --system--
-----cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa
st
0 0 0 8428 11508 711444 0 0 47437 0 4545 3631 2 11 86 2
0
1 0 0 8428 11508 711444 0 0 47309 0 4544 3620 2 11 84 2
0
die Kiste ist also ziemlich "idle" ... und scheint mir auch nicht zu
sehr auf i/o zu warten.
Beim direkten Lesen von Disk siehts allerdings so aus:
procs --------memory--------- ---swap-- -----io-- --system--
-----cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa
st
0 1 0 7668 13788 709928 0 0 82566 0 886 1427 0 11 0 88
0
0 1 0 8164 14180 708744 0 0 80027 0 855 1383 0 10 0 90
0
... von daher scheint die Kiste beim Lesen von Platte an ihrer Grenze zu
sein ...
> Wie ist die Window Size ?
standard
> Wie sind die Samba tuneables eingestellt ?
read raw = yes
write raw = yes
aio read size = 16384
aio write size = 16384
aio write behind = true
use sendfile = Yes
socket options = TCP_NODELAY IPTOS_LOWDELAY
Mich beschleicht das Gefühl, dass die Kiste für "schnelles" Lesen von
Platte zu "schnelles" Netzwerk zu schwach ist ... kann das sein?
Sven P. schrieb:> Nu, TCP/IP-Overhead, Protokollstack, Dateisystem, SMB1 ist ein dämliches> Protokoll...
Mit TCP/IP Overhead alleine kann man den Einbruch IMHO nicht erklären
... sooo viel Overhead hat TCP/IP auch wieder nicht.
SMB ist dämlich - leider ist es das Protokoll das so ziemlich jeder
Mediaplayer, etc. kann ... :/
JosefDermler schrieb:> siehe oben - mit FTP kommen ich auf ähnliche Werte. Liegen im Bereich> von 45 MB/sec
smb wird ftp schwerlich toppen können. Dann sei damit zufrieden, das smb
an ftp rankommt.
Wer misst misst Mist schrieb:> smb wird ftp schwerlich toppen können. Dann sei damit zufrieden, das smb> an ftp rankommt.
naja ... das smb nicht an ftp rankommt ist nicht verwunderlich.
Verwunderlich ist - zumindest für mich - allerdings, dass der Rechner
scheinbar mit 80 MB/s von Platte lesen kann, mit ca. 80 MB/s in's Netz
reinblasen kann ... aber smb/ftp dann insgesamt doch nur auf 45 MB/s
kommt.
Kann aber gut sein, dass das mit dem von mir verwendeten Mainboard
schlicht nicht geht ...
Mit SMB1 lässt sich ein Gigabit-Ethernet nicht auslasten, die
beobachteten Raten sind dafür nicht ungewöhnlich. Mit SMB2 hingegen
kommt man an den Anschlag, also auf über 100MB/s, sofern die Disk-I/O
das zulässt. Besondere CPU-Performance ist dafür nicht erforderlich,
auch ein Server der Atom-Klasse schafft das.
Voraussetzung dafür ist effektiv ein Samba 3.6 mit explizit aktiviertem
SMB2. Und mindestens Vista auf der Windows-Seite.
JosefDermler schrieb:> siehe oben - mit FTP kommen ich auf ähnliche Werte. Liegen im Bereich> von 45 MB/sec
Das allerdings sollte zu denken geben. FTP ist ziemlich effizient.
Geschieht das auch, wenn man nach einem Transfer den gleichen Transfer
nochmal durchführt, und zwar von einem File, das deutlich kleiner ist
als der beiderseits als Disk-Cache zur Verfügung stehende Speicher?
Damit kann man Effekte ineffizient arbeitender Disk-I/O ausschliessen.
JosefDermler schrieb:> Ein "cat /dev/sdb1/test.bin > /dev/null"
Wie hast du das denn zustande bekommen? /dev/sdb1 ist das nackte
Diskvolume, nicht das Filesystem. Ein /dev/sdb1/irgendwas ist
normalerweise unmöglich.
A. K. schrieb:> Geschieht das auch, wenn man nach einem Transfer den gleichen Transfer> nochmal durchführt, und zwar von einem File, das deutlich kleiner ist> als der beiderseits als Disk-Cache zur Verfügung stehende Speicher?> Damit kann man Effekte ineffizient arbeitender Disk-I/O ausschliessen.
grad probiert ... wenn ich ein 500 MB File übertrage, geht der erste
Transfer mit den üblichen 45 MB/s ... kopiere ich dann die selbe Datei
gleich nochmal, bin ich bei 75-80 MB ...
Damit ist wohl klar, dass der Disk-I/O etwas "bescheiden" ist :/
A. K. schrieb
> Wie hast du das denn zustande bekommen? /dev/sdb1 ist das nackte> Diskvolume, nicht das Filesystem. Ein /dev/sdb1/irgendwas ist> normalerweise unmöglich.
korrekt ... die Zeile ist natürlich falsch, eigentlich hätte es
/mnt/sdb1/ heissen sollen ...
JosefDermler schrieb:> grad probiert ... wenn ich ein 500 MB File übertrage, geht der erste> Transfer mit den üblichen 45 MB/s ... kopiere ich dann die selbe Datei> gleich nochmal, bin ich bei 75-80 MB ...>> Damit ist wohl klar, dass der Disk-I/O etwas "bescheiden" ist :/
Oder der Bus, lass mich raten, PCI und kein PCIe. Normales PCI ist zu
langsam für Gigabit.
Wer misst misst Mist schrieb:> Oder der Bus, lass mich raten, PCI und kein PCIe. Normales PCI ist zu> langsam für Gigabit.
Jedenfall dann, wenn sowohl Disk als auch Network durch den gleichen
Flaschenhals müssen.
Wer misst misst Mist schrieb:> Oder der Bus, lass mich raten, PCI und kein PCIe. Normales PCI ist zu> langsam für Gigabit.
ok. again what learned.
Yep, kein PCIe ...das Board ist schon "etwas" älter :)
Ich werd' den alten Krempel doch rauswerfen und mir für den Fileserver
was aktuelleres holen ...
danke!
