Dotaz: Mizerná rychlost samby a lokálních disků

[Petr_]

Zdravím, mám takový podivný problém. Na gigabitové lokální síti ( na testovací stanici s win dá IPerf asi 980Mbit down, 430 up). Přes ftp to jede podobně. Nicméně přes sambu jsou ty výsledky dost tragické od 10 po asi 21 MBps při velkých souberech. Jinak ještě divnější problém, že kopírování na tomto servříku z disku na disk jede kolem 13-15MBps. Neporadil by někdo něco ? Díky

Odpovědi

[lertimir]

Takže FTP přenos na server a z něj je významně rychlejší než lokální kopírování?

[Petr_]

Ano, to je právě to nejpodivnější. I jsem kontroloval, zda jedou oba v DMA.

[Petr_]

Jinak: server:~# hdparm -T /dev/sda

/dev/sda: Timing cached reads: 1328 MB in 2.00 seconds = 663.84 MB/sec server:~# hdparm -T /dev/sdb

/dev/sdb: Timing cached reads: 1312 MB in 2.00 seconds = 656.28 MB/sec

[lertimir]

to je nezajímavé číslo. Co hdparm -t? to skutečná rychlost dat s disku?

[Petr_]

/dev/sda:

Timing buffered disk reads: 344 MB in 3.01 seconds = 114.35 MB/sec

server:/usr/local/etc# hdparm -t /dev/sdb /dev/sdb:

Timing buffered disk reads: 288 MB in 3.01 seconds = 95.80 MB/sec

[lertimir]

a jaké jsou na discích file systémy, jedou v jádře nebo ve FUSE? asi to bude chtít nějaký monitoring jádra co se tam děje pří lokálním kopírování.

[Petr_]

ext3 na NTFS (ale takle je to dočassně, jen jsem potřebovat překlopit cca 600GB na linux). Jinak podpora pro oba fs je kompilována jako modul jádra. Ale to bych až tak neřešil. Nejvíc mě pálí ta samba.

[Petr_]

tak jsem přišel na to, že extrémní nastavení bufferů SO_SNDBUF a SO_RCVBUF rychlost na pár vteřin opravdu výrazně zvýší (až někam k 90MBps down, což se blíží limitu sítě) nicméně po pár vteřinách to jde do háje.

[lertimir]

Chápu, že prakticky to kopírování souboru na serveru tak moc nepálí, ale myslím že v porozumění toho proč je lokální kopírování je klíč. Netuším proč. ale jako by lokální kopírování a samba přistupovaly k disku ještě přes nějakou vrstvu, která tam naskládá nějaké waity, zatímco FTP server k disku jde příměji. Velké buffry mohou zápisovou komunikaci chytnout do sebe, předtím než je skutečně zapsána do disku. zvýší se tím i rychlost na čtení ze serveru, tedy že samba čte první vteřiny rychleji? Ale tady by asi pomohli lidi co umí monitorovat jádro. Chtělo by to vytvořit nějaký log.

[Petr_]

Opravdu to tak vypadá, pokud ty buffery nastavím na velké hodnoty a zajistím, že ty data tam budou, jede to plnou rychlostí. Zjevně to vypadá na něco mezi sambou a diskem. Otázka je co a jak to najít. Jinak problém je na debianovských distribučních jádrech 2.6.26, .32 i na vlastním .34 (AMD64), takže bych spíš něco čekal v sambě. Až budu v pátek doma, zkusím ji skompilovat ze zdrojáků novou, místo distribučního balíčku.

[Petr_]

Tak kompilace vlastní samby se moc nepovedka, 3.5.5 padala s core dump, 3.4.9 sice běžela, ale sdílení se mi nepovedlo royjet. Jinak jsem ykonvertoval dis na ext4 a rychlost lokálního kopírování stoupla asi na 40MBps, samba asi na 15. Naopak přenos po ftp asi o 10 spadl.

[Petr_]

Tak je to očividně něco s diskem, pokud do samby mountnu jiný, rychlost stoupne na 40-50MBps. Akorát absolutně nevím, co to způsobuje.

[lertimir]

možná se pletu, ale myslel jsem že ntfs-3g je mountováno v userspace a ne kernelu. a muže to být i tím že disk pomalu odchází.

[d'areback]

Nechce to udelat ext4 na xfs na reiser4 na ext3 na ntfs na btfrs na reiser3 na fat ? Treba to vyrazne zrychli :)

[Heron]

Obraz jednoho souborového systému uložený do souborů na jiném fs je docela běžná věc.

[d'areback]

NTFS

[JF]

Zkus třeba tohle:

# Speedup HDD
hdparm -X66 -d1 -u1 -c3 -m16 /dev/hda
hdparm -X66 -d1 -u1 -c3 -m16 /dev/hdd

Zapíná to DMA, IRQ, načítání sektorů dopředu. Na některém HW některé parametry nefungují, to si musíš vyzkoučet sám. Mě to skoro zdvojnásobilo rychlost práce s diskem.