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?
Overhead vom TCP/IP. Das sind ebenfals Daten, die verschickt werden müssen
Was sagt top? smb.conf? Meine Einstellungen:
1 | socket options = TCP_NODELAY IPTOS_LOWDELAY |
2 | aio write size = 16384 |
3 | aio read size = 16384 |
SO_SNDBUF und SO_RCVBUF sollten nicht gesetzt sein.
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!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.