У меня есть сервер CentOS 5.6 с базовой установкой Samba. Он имеет 8-дисковый Raid 5, подключенный к Areca 1880, тесты hdparm вернули мне ~ 450 Мбит / с, и я могу подтвердить это с помощью dd to / dev / null. Для передачи файлов в сеть используется карта Myricom 10 ГБ, а все клиенты - 1 ГБ Broadcom / Intel / и т. Д. На одном коммутаторе.
Проблема, с которой я столкнулся, кажется довольно постоянной: производительность копирования файлов с одним потоком оставляет желать лучшего, если файлы не были кэшированы в память на сервере. Я говорю о файлах размером 9-12 МБ, если я копирую файл размером 1 ГБ, производительность зашкаливает, обычно 90% + на клиентах 1 ГБ. Когда я копирую файлы размером 9–12 МБ, скажем, 100 из них, он будет использовать примерно 40–50%, после того как они будут кэшированы на сервере, он МОЖЕТ БЫТЬ 55–65% использования на клиентской сетевой карте 1 ГБ, но никогда больше. Зачем?!?
Я могу скопировать несколько кэшированных последовательных файловых последовательностей и получить, возможно, более 85% использования на клиентской сетевой карте, почему одна файловая последовательность не может достигать 95% +? Все клиенты настроены на выгрузку пакетов tx / rx на адаптер, к сожалению, они не используют Jumbo Frames, но я тестировал с включенным Jumbos и все еще видел ту же производительность.
Большой последовательный доступ - лучший сценарий, и, как вы говорите, ваша система насыщает канал в этом сценарии.
Использование множества файлов меньшего размера по сравнению с одним большим файлом приводит к появлению метаданных и, возможно, накладных расходов на блокировку. Я предполагаю, что с более чем одним потоком вы получаете несколько передаваемых данных, а в многоядерной системе они могут делать это параллельно, увеличивая пропускную способность. Такое поведение, кажется, указывает на то, что вы ограничены однопоточной производительностью для многих небольших файлов. Если вы можете протестировать с SSD, вы узнаете, связана ли проблема с производительностью с дисковым вводом-выводом (блокировка, изменение времени доступа, метаданные) или ваш процессор привязан (вы также можете увидеть, как процесс самбы пожирает все ядро на top отображать при передаче данных, что было бы хорошим индикатором).
Вы также можете поиграть с SystemTap и посмотреть, где именно ядро тратит время в сценариях «большой файл» и «много маленьких файлов».