FreeBSD 10G Samba speed
lexa - 26/Ноя/2018 14:02
В догонку к позавчерашнему.
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
виден небольшой запас, процентов 10 еще можно добавить
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 -
Ну вот samba 4.6/4.7 - упирается в ядро CPU, насколько я вижу. 4.3 (которая у меня была побыстрее) - в pkg нет, собирать немножко лень.
4.8 - упирается хз во что, не вижу упора, но тем не менее.
С другой стороны Win10, совокуплено через асусовский свитч (но mbuffer-у свитч не мешал)
Спасибо за совет с lz4/нулями
Спасибо за совет с 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
Ну вот я померял этим diskspd из пустого файла — и был приятно удивлён.
И даже при чтении в один тред у меня smbd (4.8) выжирает 184% при этом.
Это E3-1220v3.
У меня diskpd намеривает
У меня diskpd намеривает примерно вдвое меньше, чем копирование 80-гигового файла windows explorer
Ну, мне некуда копировать
Ну, мне некуда копировать файл так быстро. FAR'ом в NUL медленно. Эксплорер упирается в SATA SSD на декстопе.
И, да, у diskspd много-много разных ключей :-)
Да, без ключа -Sh (который я
Да, без ключа -Sh (который я откуда-то скопипастил) - скорость стала равна эксплореру.
6.5 гигабит по perf monitor (смотрю ж и на сеть тоже).
Со старого ящика - тоже ~800MB/sec, а diskpd кажет 350.
Ключи перебирать не буду, копирование на nvme - оно мне понятно хотя бы.
У меня все числа с -Sh…
У меня все числа с -Sh…
Нипанятна.
А FreeBSD - 12-я?
А FreeBSD - 12-я?
11.2-STABLE. 12-ую на сервер
11.2-STABLE. 12-ую на сервер я пока не.
А что-то тюнил для ix (или
А что-то тюнил для ix (или для tcp, хотя вот тюнинг tcp заметных различий не дал мне)?
$ cat /boot/loader.conf
$ 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, конечно.
mtu=9000, конечно.
На винде тоже число буферов в очередях выкручено на максимум.
Ну у меня примерно то же
Ну у меня примерно то же самое по смыслу, неожиданных настроек не увидел.
Вот сейчас 672MB/s с нового ящика, 860 со старого.
У меня diskpd намеривает примерно вдвое меньше
diskspd -W0 -d30 -s -b128k -o32 Z:\файл
Читаем файл последовательно без прогрева, 30 сек, блоками 128KB, в один поток с глубиной очереди 32. Можно поиграться с размером recordsize и читаемым блоком. explorer очень хорошо утилизирует пропускную способность сети. Реальное копирование больших файлов где-то 1,13-1,15GB/s.
чуть меньше 6 гигабит у меня.
чуть меньше 6 гигабит у меня. Надо что-то тюнить, не знаю что и где
Надо что-то тюнить, не знаю что и где
Сложно в тёмную что-то советовать. Если поиграть в дедукцию :-), то mbuffer показывал полосу между двумя freebsd и они обе не могут утилизировать канал с win. Может стоит посмотреть в сторону win? Антивирус например или ещё что-то, что может влиять на сеть?
Антивирус выключен на 10G
Антивирус выключен на 10G-портах, но вообще да, винда под подозрением
Актуальная в портах всё же
Актуальная в портах всё же samba48 (с 24 марта 2018).
И вот три часа назад обновление: https://svnweb.freebsd.org/ports?view=revision&revision=486043
4.8 кстати побыстрее чем 4.3,
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.последняяя_в_портах
4.8.последняяя_в_портах
И, да, в один поток ровно та же суммарная скорость. От размера блока — зависит, от размера очереди — чуть-чуть зависит, от количества тредов — нет, всё равномерно размазывается на треды, очень ровненько, я пробовал от 1 до 8 (у меня 8 псевдоядер на клиенте, это i7-6700K).
1 поток, 32K блок, очередь 32
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.