Назад | Перейти на главную страницу

Производительность чтения Samba

Всякий раз, когда я читаю большой файл со своего сервера Samba, я получаю около 40 МБ / с. Если я снова прочитаю тот же файл, скорость внезапно вырастет до 70 МБ / с.

Почему я не получаю 70 МБ / с в первый раз? Диски легко развивают скорость до 95 МБ / сек. Должна ли Samba кэшировать весь файл в ОЗУ, чтобы получить производительность или что-то в этом роде?

При записи файлов на сервер я каждый раз получаю 95+ МБ / сек, большая разница.

Я попытался установить некоторые параметры сокета (TCP_NODELAY IPTOS_LOWDELAY SO_SNDBUF = 65535 SO_RCVBUF = 65535), но они, похоже, мало помогают.

Итак, какие-нибудь советы о том, как улучшить скорость чтения в Samba?

Примечание: Диски - 2x1TB Samsung Spinpoint F1 7200 RPM, сконфигурированные в программном массиве RAID 1.

Обновить: Кажется, что клиент имел столько же, если не больше, дел с этой проблемой, как и сервер. Я использовал свой верный старый Total Commander, который сейчас кажется слишком старым. Когда я вместо этого копирую файлы с помощью проводника Windows, даже некэшированные файлы читаются довольно быстро. Спасибо за вашу помощь.

Во-первых, эти параметры сокетов TCP предназначались для ядер 2.4, и в списке рассылки Samba разработчики неоднократно заявляли, что они не имеют смысла для ядер 2.6.

Кроме того, здесь что-то не так с вашими цифрами. Невозможно, чтобы 2 диска SATA в конфигурации RAID1 (зеркала) дали вам скорость записи 95 МБ / с, и я очень сомневаюсь, что вы также увидите такую ​​высокую скорость чтения. За исключением, может быть, самой внешней дорожки диска. Как вы оцениваете свой том RAID? Имейте в виду, что dd не является тестом файловой системы.

Гигабитные скорости также могут потреблять значительное количество циклов процессора, если ваши сетевые адаптеры относятся к потребительскому уровню. Так что, если у вас более медленный процессор в системе, не исключайте процессор как бутылочное горлышко.

Также имейте в виду, что диски и ЦП на сервере и клиенте должны поддерживать скорость, которую вы пытаетесь достичь, поэтому не смотрите на сервер как на источник узкого места, поскольку это просто как вероятно, будет на стороне клиента.

1.Попробуйте увеличить опережение чтения

# /sbin/blockdev --getra /dev/sdb
256
# /sbin/blockdev --setra 16384 /dev/sdb

2.Попробуйте изменить планировщик ввода-вывода и найдите тот, который лучше всего подходит для вашей рабочей нагрузки.

# cat /sys/block/hda/queue/scheduler
noop [anticipatory] deadline cfq
echo deadline > /sys/block/hda/queue/scheduler

До сих пор все ответы больше относились к дискам, чем к конфигурации RAID. Возможно, вам помогут вопросы 19 и 4 этого руководства: Программный RAID HOWTO.

Другое дело сетевая сторона. У вас есть ПАЛЕЦ включен на вашей сетевой карте?

И последнее: вы проверяли, что ваше узкое место не на стороне клиента? Возможно, ваш FTP-клиент хранит в ОЗУ больше данных, чем служба CIFS. И это, возможно, одна из причин, почему FTP работает быстрее.

Кэширование диска Linux является причиной того, что второе чтение выполняется быстрее, не говоря уже о каком-либо кэшировании H / W диска, которое может быть задействовано.

Чтобы повысить производительность чтения: используйте чередование дисков, увеличьте ОЗУ, перейдите на следующий уровень аппаратного интерфейса для ваших дисков (замените SATA на SAS или FC4), используйте более быстрые диски (15 КБ об / мин вместо 10 КБ), добавьте ОЗУ в свой кэш RAID.

Улучшение 70 МБ / с будет дорого, но вы сможете немного улучшить скорость первого чтения.