FreeBSD 10G Samba speed

В догонку к позавчерашнему.

Samba 4.8 пишет (и читает) со скоростью дисков, во всяком случае пока этих дисков 3 (и писать можно ~600MB/sec).

Вот на netstat видно, например:

# netstat -I ix0 1
            input            ix0           output
   packets  errs idrops      bytes    packets  errs      bytes colls
     70801     0     0  636957461      24946     0    1661685     0
     65798     0     0  592032063      24596     0    1639413     0
     69470     0     0  624964103      24249     0    1615565     0
     64249     0     0  578234195      23707     0    1579277     0
     69714     0     0  627279903      24907     0    1656832     0
     64724     0     0  582487299      24398     0    1624537     0

При этом по top -SHPI виден небольшой запас, процентов 10 еще можно добавить

last pid:  1463;  load averages:  5.94,  4.42,  3.08    up 0+00:40:54  13:57:14
475 processes: 11 running, 414 sleeping, 1 stopped, 49 waiting
CPU 0:  3.5% user,  0.0% nice, 40.7% system,  0.0% interrupt, 55.8% idle
CPU 1:  2.3% user,  0.0% nice, 41.9% system,  1.2% interrupt, 54.7% idle
CPU 2:  2.3% user,  0.0% nice, 44.2% system,  0.0% interrupt, 53.5% idle
CPU 3:  3.5% user,  0.0% nice, 44.2% system,  1.2% interrupt, 51.2% idle
CPU 4:  4.7% user,  0.0% nice, 43.0% system,  0.0% interrupt, 52.3% idle
CPU 5:  0.0% user,  0.0% nice, 12.8% system, 59.3% interrupt, 27.9% idle
CPU 6:  4.8% user,  0.0% nice, 34.5% system,  1.2% interrupt, 59.5% idle
CPU 7:  4.7% user,  0.0% nice, 44.2% system,  2.3% interrupt, 48.8% idle
Mem: 3384K Active, 33M Inact, 154M Laundry, 15G Wired, 263M Buf, 220M Free
ARC: 12G Total, 212K MFU, 10G MRU, 1893M Anon, 23M Header, 5690K Other
     11G Compressed, 11G Uncompressed, 1.02:1 Ratio
Swap:

  PID USERNAME   PRI NICE   SIZE    RES STATE   C   TIME    WCPU COMMAND
 1432 root        97    0   174M   163M CPU0    0   3:37  87.59% smbd{smbd}
   11 root       155 ki31     0K   128K RUN     0  30:31  57.61% idle{idle: cpu
   11 root       155 ki31     0K   128K RUN     1  30:30  57.37% idle{idle: cpu
   11 root       155 ki31     0K   128K CPU6    6  31:37  56.06% idle{idle: cpu
   11 root       155 ki31     0K   128K CPU2    2  30:36  55.06% idle{idle: cpu
   11 root       155 ki31     0K   128K CPU3    3  30:36  52.15% idle{idle: cpu
   11 root       155 ki31     0K   128K CPU4    4  30:23  50.60% idle{idle: cpu

P.S. Сначала я в этих тестах уперся в checksum=skein, каковые с прошлых тестов остались.

 

Comments

mbuffer показал пропускную способность сети 1+GB/s. Думаю от самбы следует ожидать подобного результата.

Не хочу возиться с рамдиском, поэтому увидим когда полноценный массив (с L2) туда приедет.

Но вообще - ну скорее таки меньше.

Если затюнить - заставить использовать мегабайтное окно TCP и пр.

Хрен эту самбу разберет.
Ну то есть с пару лет назад я столкнулся с тем, что samba 4.3 работала быстрее, чем 4.4 (а более новых тогда вроде бы не было, или что-то было в бете), ну так с тех пор и работает у меня.

Но блин, 4.3 уже в портах нету, и не сравнить.

(11.1 + samba 4.4) <-> win 10 без тюнинга на 10 гигабитах упирается в 1,18GB/s. Проверено не на одной машине. Правда процессоры помощнее.

Ну вот samba 4.6/4.7 - упирается в ядро CPU, насколько я вижу. 4.3 (которая у меня была побыстрее) - в pkg нет, собирать немножко лень.
4.8 - упирается хз во что, не вижу упора, но тем не менее.

С другой стороны Win10, совокуплено через асусовский свитч (но mbuffer-у свитч не мешал)

Спасибо за совет с lz4/нулями, докладываю:
samba 4.6, 4.7 (из настроек SO_RCVBUF=2097152 SO_SNDBUF=2097152 остальное все что пробовал - не влияет на производительность):
~660MB/sec read speed (копировал Windows Explorer, он побыстрее), smbd ложится на 100% CPU и все.

samba 4.8 (тот же конфиг): 800-810, может быть даже больше, smbd 130% CPU ну и видно что там worker threads запускаются.

Самбы 4.9 в портах отчего-то нет, хотя уже два месяца как вышла.

При этом Changelog у самбы не очень внятный, они пишут про новые features, а вот то что aio реализовали иначе в 4.8 - с большим трудом нашел.

В принципе, 800+ меня устраивает. То есть конечно у меня есть программы, которые умеют читать больше (FastRawViewer, если его кормить нежатыми сонями - гигабайта полтора/сек может выжрать), но в реальности это все уже не надо.

Не факт. У меня когда не было 10G диски отдавали где-то 5 гигабит, сеть под iperf'ом легко отдавала совершенно полный гигабит, а файлы читались на 600-750 мегабит.

Когда появилось 10G — ну, всё хорошо (диски вдвое медленней сети), но если диск разгонятся быстрее 10G, я не уверен, что вот так просто получу полные 10G.

Ну вот в предыдущий заход у меня samba43 была быстрее более новых.

Достану пожалуй из https://svn.freebsd.org/ports/branches/2017Q2/net/samba43/ и соберу руками, интересно...

Актуальные, как написано выше, 46/47 - ложатся на процессор (на одно ядро)

Ну вот я померял этим diskspd из пустого файла — и был приятно удивлён.
И даже при чтении в один тред у меня smbd (4.8) выжирает 184% при этом.
Это E3-1220v3.

У меня diskpd намеривает примерно вдвое меньше, чем копирование 80-гигового файла windows explorer

Ну, мне некуда копировать файл так быстро. FAR'ом в NUL медленно. Эксплорер упирается в SATA SSD на декстопе.

И, да, у diskspd много-много разных ключей :-)

Да, без ключа -Sh (который я откуда-то скопипастил) - скорость стала равна эксплореру.
6.5 гигабит по perf monitor (смотрю ж и на сеть тоже).
Со старого ящика - тоже ~800MB/sec, а diskpd кажет 350.

Ключи перебирать не буду, копирование на nvme - оно мне понятно хотя бы.

У меня все числа с -Sh…

Нипанятна.

А FreeBSD - 12-я?

11.2-STABLE. 12-ую на сервер я пока не.

А что-то тюнил для ix (или для tcp, хотя вот тюнинг tcp заметных различий не дал мне)?

$ cat /boot/loader.conf
autoboot_delay="3"
beastie_disable="YES"

kern.hwpmc.nsamples=4096

kern.geom.label.disk_ident.enable=0
kern.geom.label.gptid.enable=0

hw.acpi.cpu.cx_lowest=C2

hw.igb.max_interrupt_rate=16000
hw.igb.rx_process_limit=4096
hw.igb.tx_process_limit=4096
hw.igb.rxd=4096
hw.igb.txd=4096

hw.ix.max_interrupt_rate=16000
hw.ix.rx_process_limit=4096
hw.ix.tx_process_limit=4096
hw.ix.rxd=4096
hw.ix.txd=4096

net.link.ifqmaxlen=16384

zfs_load="YES"

$ cat /etc/sysctl.conf
net.inet.tcp.recvbuf_auto=1
net.inet.tcp.recvbuf_inc=131072
net.inet.tcp.recvbuf_max=16777216
net.inet.tcp.recvspace=131072
net.inet.tcp.sendbuf_auto=1
net.inet.tcp.sendbuf_inc=131072
net.inet.tcp.sendbuf_max=16777216
net.inet.tcp.sendspace=131072
net.inet.tcp.maxtcptw=102400
net.inet.tcp.mssdflt=8800
kern.ipc.maxsockbuf=16777216
kern.ipc.somaxconn=8192

net.inet.tcp.rfc6675_pipe=1

vfs.read_max=32

vfs.zfs.min_auto_ashift=12

vfs.nfsd.server_min_nfsvers=4

dev.igb.0.fc=0
dev.igb.1.fc=0

dev.ix.0.fc=0
dev.ix.1.fc=0

$

mtu=9000, конечно.
На винде тоже число буферов в очередях выкручено на максимум.

Ну у меня примерно то же самое по смыслу, неожиданных настроек не увидел.

Вот сейчас 672MB/s с нового ящика, 860 со старого.

diskspd -W0 -d30 -s -b128k -o32 Z:\файл
Читаем файл последовательно без прогрева, 30 сек, блоками 128KB, в один поток с глубиной очереди 32. Можно поиграться с размером recordsize и читаемым блоком. explorer очень хорошо утилизирует пропускную способность сети. Реальное копирование больших файлов где-то 1,13-1,15GB/s.

чуть меньше 6 гигабит у меня. Надо что-то тюнить, не знаю что и где

Сложно в тёмную что-то советовать. Если поиграть в дедукцию :-), то mbuffer показывал полосу между двумя freebsd и они обе не могут утилизировать канал с win. Может стоит посмотреть в сторону win? Антивирус например или ещё что-то, что может влиять на сеть?

Антивирус выключен на 10G-портах, но вообще да, винда под подозрением

Актуальная в портах всё же samba48 (с 24 марта 2018).

И вот три часа назад обновление: https://svnweb.freebsd.org/ports?view=revision&revision=486043

4.8 кстати побыстрее чем 4.3, со старого ящика имею 900+ MB/sec на чтение (а было 700+ с 4.3 вчера)

Поскольку диски - медленнее (кроме L2ARC), на этом и остановимся.

Хотя не, офигеть:

Read IO
thread | bytes | I/Os | MiB/s | I/O per s | file
------------------------------------------------------------------------------
0 | 18495766528 | 282223 | 293.98 | 4703.68 | big-file.bin (64GiB)
1 | 18469486592 | 281822 | 293.56 | 4697.00 | big-file.bin (64GiB)
2 | 18495766528 | 282223 | 293.98 | 4703.68 | big-file.bin (64GiB)
3 | 18485542912 | 282067 | 293.82 | 4701.08 | big-file.bin (64GiB)
------------------------------------------------------------------------------
total: 73946562560 | 1128335 | 1175.34 | 18805.45

Это треда, очередь по 32 запроса, блок 64 кб. Конечно, блоком в 4кб помедленней, всего 192MiB/s т.е. всё упирается в IOPS (как ни крути чуть меньше 50K iops).

А 10G насыщается уже на 32K блоке.

Ну да, это пустой (дырявый) файл на ZFS + samba.

Версия самбы?

Ну и я меряю в один поток. Много потоков меня не интересуют.

4.8.последняяя_в_портах

И, да, в один поток ровно та же суммарная скорость. От размера блока — зависит, от размера очереди — чуть-чуть зависит, от количества тредов — нет, всё равномерно размазывается на треды, очень ровненько, я пробовал от 1 до 8 (у меня 8 псевдоядер на клиенте, это i7-6700K).

1 поток, 32K блок, очередь 32

Read IO
thread | bytes | I/Os | MiB/s | I/O per s | file
------------------------------------------------------------------------------
0 | 133577900032 | 4076474 | 1061.58 | 33970.67 | big-file.bin (64GiB)
------------------------------------------------------------------------------
total: 133577900032 | 4076474 | 1061.58 | 33970.67

Очередь важна при рандоме: 1 поток, 32K блок, очередь 1 (синхронно)
ead IO
thread | bytes | I/Os | MiB/s | I/O per s | file
------------------------------------------------------------------------------
0 | 4880236544 | 148933 | 77.57 | 2482.20 | big-file.bin (64GiB)
------------------------------------------------------------------------------
total: 4880236544 | 148933 | 77.57 | 2482.20

Странная херня у этой тестилки, если поставить block size 1Mb:
Read IO
thread | bytes | I/Os | MiB/s | I/O per s | file
------------------------------------------------------------------------------
0 | 67696066560 | 64560 | 2151.99 | 2151.99 | file.img (20GiB)
------------------------------------------------------------------------------
total: 67696066560 | 64560 | 2151.99 | 2151.99

Лучше я по старинке, Explorer

За меньшее время, чем заданно файл был прочитан полностью и начал читаться с начала, а файл уместился в кэш win и стал читаться оттуда. Видим среднюю скорость :-). Тоже нарывался.

Со стороны zfs достаточно одного hdd. Для чтения создать в датасете с lz4 большой файл забитый нулями или ещё быстрее будет читать большой sparse файл. Для записи подойдёт файл забитый нулями в датасет с lz4. На стороне win если нет быстрых nvme (или жалко) для чтения можно использовать diskspd.