Почему мой сервер самбы служит данным так медленно, даже когда упомянутые данные кэшируются?
:~# vgscan -vv
Setting global/locking_type to 1
File-based locking selected.
Setting global/locking_dir to /lib/init/rw
Locking /lib/init/rw/P_global WB
Wiping cache of LVM-capable devices
/dev/sndstat: stat failed: Datei oder Verzeichnis nicht gefunden
Wiping internal VG cache
Reading all physical volumes. This may take a while...
Finding all volume groups
/dev/md0: size is 192512 sectors
/dev/md0: size is 192512 sectors
/dev/md0: No label detected
/dev/md1: size is 5863552 sectors
/dev/md1: size is 5863552 sectors
/dev/md1: No label detected
/dev/md2: size is 303596160 sectors
/dev/md2: size is 303596160 sectors
/dev/md2: lvm2 label detected
Locking /lib/init/rw/V_systemlvm RB
Finding volume group "systemlvm"
/dev/md2: lvm2 label detected
Found volume group "systemlvm" using metadata type lvm2
Unlocking /lib/init/rw/V_systemlvm
Unlocking /lib/init/rw/P_global
Большой последовательный доступ - лучший сценарий, и, как вы говорите, ваша система насыщает канал в этом сценарии.
Многие файлы меньшего размера по сравнению с одним большим файлом приводят к метаданным и, возможно, к блокировке накладные расходы. Я предполагаю, что с более чем одним потоком вы получаете несколько передаваемых данных, а в многоядерной системе они могут делать это параллельно, увеличивая пропускную способность. Такое поведение, кажется, указывает на то, что вы ограничены однопоточной производительностью для многих небольших файлов. Если вы можете протестировать SSD, вы узнаете, связана ли проблема с производительностью с дисковым вводом-выводом (блокировка, изменение времени доступа, метаданные) или ваш процессор ограничен (вы также можете увидеть, как процесс самбы съедает все ядро на верхний дисплей при передаче данных, что было бы хорошим индикатором).