Забыл, конфиг самбы дефолтный.

я  бы в первую очередь top смотрел. Наблюдал на машине с фрёй при большом трафике 100% загрузку проца.

кернел дистрибутивный?

что с другими сервисами? scp?

Телепаты в отпуске

Для начала надо разобраться, где именно затык. Возможно, что-то не так
с сетью. Возможно, тормозит ФС. Возможно, тормозит сама Samba.

Про сеть. Просмотрите выхлоп

ifconfig -a

на предмет collisions и errors.

Если там нули, устройте следующую проверку. Потребуется еще одна
машина с *NIX. На этой машине (назовем ее host1) запустите

nc -l -p 8888 -q1 >/dev/null

ПОСЛЕ этого на проверяемой:

dd if=/dev/zero bs=1M count=512 | nc -w1 host1 8888

Вот то, что dd скажет, можно считать оценкой производительности сети
(она не особо точная, но по порядку величины правильная).

А теперь про ФС.

> Скорость диска(hdparm -Tt) = 192MB/c

А какая "скорость" у ФС? Что за ФС? Не забыли ли при ее создании указать
swidth (или stripe-size)?

Ошибок и коллизий нет.

Вторую машину с *nix пока не могу запустить.

Через ftp скорость примерно 60000 килобит/с.

Файловая система EXT3.

>А какая "скорость" у ФС? Что за ФС? Не забыли ли при ее создании указать swidth (или stripe-size)?

Это у него только скорость чтения кэша

> Через ftp скорость примерно 60000 килобит/с.

Ага, значит и сеть, и ФС работают нормально.

> Вторую машину с *nix пока не могу запустить.

Уже не нужно (раз другие протоколы работают более-менее сносно).

> Файловая система EXT3.

А что, если вместо нее что-нибудь приличное сделать, например XFS?
Вменяемая скорость по ftp -- это хорошо, конечно, но там нет блокировок
и прочих прелестей, которые предъявляют довольно высокие требования к ФС.

для гигабита маловато будет. >по гигабитному подключению наблюдается скорость в районе 13000 килобит/с >На Этой же машине винда 2003 показывает 60000.

чем вы скорость на smb-сервере смотрите? что за чудеса такие?

stripe как в контроллере - 32

> Это у него только скорость чтения кэша

Я знаю. Тем не менее, операции с ФС тоже кешируются (как ядром, так и самим
диском). Смысл вопроса в том, что ФС может тормозить, если ей не рассказали
про RAID, хотя производительность самого блочного устройства при этом
нормальная.

> по гигабитному подключению наблюдается скорость в районе 13000 килобит/с

А дисковая подсистема увас тоже RAID10 из 4x SCSI 10000rpm?

А как меряли?

> по гигабитному подключению наблюдается скорость в районе 13000 килобит/с

> На этой же машине винда 2003 показывает 60000.
                               ^^^^^^^^^^

Есть анекдот такой. Приходит 70-летний дед ко врачу, жалуется на плохую
потенцию. 
Доктор:  А что ж Вы хотели, возраст...
Дед: А моему соседу 80, и он говорит, что у него все получается.
Доктор: Ну так и Вы говорите.

Показывать и я могу. Серьезно, а как получились-то эти 13000 и 60000?
что будет, если с другой *NIX машины подцепиться к тестируемой
(smbclient или mount -t cifs), и честно померять? Как-нибудь так:

[сервер]
cd /куда/надо
dd if=/dev/zero of=test.file bs=1M count=4096

[потом на клиенте]
time smbclient //host/dir -c 'get test.file'

Я банально мерял копированием в total commander в случае с win и *nix

Кстати при копировании с *nix наблюдаются затыки

В топ нагрузка самбой самоя большая - при копировании 11 ГА мелких файлов загрузка двух xeon 3000 на 15%

буферы менял, не помогло

в студию, что то мне подсказывает что плохо ты их менял.

socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=131072 SO_SNDBUF=131072

Менял от 8192 и до 262144

Пока что (мне) не очевидно, кого пинать -- сеть или ФС.

По поводу сети.

> socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=131072 SO_SNDBUF=131072

Это только полдела. Покажите, что у Вас говорят

cat /proc/sys/net/core/netdev_max_backlog
cat /proc/sys/net/core/rmem_max
cat /proc/sys/net/core/wmem_max
cat /proc/sys/net/ipv4/tcp_rmem
cat /proc/sys/net/ipv4/tcp_wmem
cat /proc/sys/net/ipv4/tcp_wmem

А теперь -- про ФС.

Можно попытаться немножко помочь VFS:

echo 80 > /proc/sys/vm/vfs_cache_pressure
echo 90 > /proc/sys/vm/swappiness
echo 30 > /proc/sys/vm/dirty_background_ratio
echo 60 > /proc/sys/vm/dirty_ratio

И таки советую попробовать нормальную ФС (XFS, ext2), хотя бы ради проверки.

Вдогонку.

> Менял от 8192 и до 262144

У ядра есть (настраиваемый) верхний предел для размера буферов. То, что
вы указали в конфиге большое значение, еще не значит, что оно в
действительности использовалось. Потому я Вас и попросил показать разные
настройки из /proc/sys/net.

Всем спасибо!

Проблема была в 6.06.2 amd64

а именно в ядре собранном под xeon

Обновился до 8.04 server, попробовал xfs, reiserfs, jfs.

организация работает с мрачной софтиной, написанной индусами (за еду)под названием "Аура".

Написанная на foxpro, размер баз 5 и 7 ГА(куча мелких файлов).

Для работы с ней оптимальным вариантом оказалась xfs с размером

sunit=128,swidth=256 при размере страйпа 32(при страйпе 64

sunit=256,swidth=512 скорость линейного чтения немного упала)размер

журнала=32, размер блока=4096

оптимальный размер буфера samba под эти задачи - 8192.

быстродействие линейного чтения сравнялось с M$2003, в реальной работе обогнало ее.

Сейчас планирую уменьшить страйп до 16, а также значение sunit=64, swidth=128

>Покажите, что у Вас говорят

cat /proc/sys/net/core/netdev_max_backlog

1000

cat /proc/sys/net/core/rmem_max

131071

cat /proc/sys/net/core/wmem_max

131071

cat /proc/sys/net/ipv4/tcp_rmem

4096 87380 4194304

cat /proc/sys/net/ipv4/tcp_wmem

4096 87380 4194304

Ага, все по умолчанию, никакой экзотики. В принципе, если захочется чуток
"ускориться" можно покрутить (в сторону увеличения) netdev_max_backlog
(особенно если клиентов много) и максимально допустимые размеры буферов.

> Проблема была в 6.06.2 amd64
> а именно в ядре собранном под xeon

А у Вас что?

> Написанная на foxpro, размер баз 5 и 7 ГА(куча мелких файлов).

В такой ситуации ext3 [censored] массово употребляет chupa-chups. Особенно,
если клиентов больше одного.

> Сейчас планирую уменьшить страйп до 16, а также значение sunit=64, swidth=128

mkfs.xfs самостоятельно справляется с подбором нужных значений, причем
весьма неплохо.