FreeBSD + 10G + Samba tune
Все утро онанировал подбирал параметры FreeBSD/Samba. Остановился пока на таком:
/boot/loader.conf
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
smb4.conf
read raw = yes write raw = yes socket options = TCP_NODELAY SO_RCVBUF=2097152 SO_SNDBUF=2097152 large readwrite = yes
Уменьшение размера буферов до 1Mb снижает скорость чтения процентов на 5, до 512к - процентов на 20.
Все кроме третьей строчки (socket options) скопировано с предыдущего ящика, может оно тоже не нужно (но на нем - было нужно).
И, в принципе, они такие не нужны (изменение относительно defaults - в районе 1-2% это близко к погрешности измерений), но пусть будут, /etc/sysctl.conf
kern.ipc.maxsockbuf=16777216 net.inet.ip.intr_queue_maxlen=2048 net.inet.tcp.recvbuf_max=16777216 net.inet.tcp.recvspace=4194304 net.inet.tcp.recvbuf_inc=524288 net.inet.tcp.sendbuf_max=16777216 net.inet.tcp.sendspace=2097152 net.inet.tcp.sendbuf_inc=32768 net.route.netisr_maxqlen=2048
Результат: 970MiB/sec на чтение при помощи diskpd с параметрами -b2M -o32 -Sh
Результат одинаков для двух ящиков (i3-6300T и Atom C3758), видимая разница в том, что на i3 smbd занимает ~98% CPU по top, а на атоме - 200+%.
Одинаковость результата наводит на мысль, что тормоза - в винде, как мне уже намекали в комментариях.
Ну и чтобы два раза не вставать: Samba 4.8 заметно быстрее всех протестированных предыдущих версий (4.3, 4.6, 4.7)
Comments
Проверь всё же влияние flow
Проверь всё же влияние flow control ;-) sysctl dev.ix.0.fc=0 на FreeBSD.
Ну и 970MiB/sec уже не выглядит как «тормоза» ;-)
Я предпочел бы 1100, это был
Я предпочел бы 1100, это был бы нормальный результат. А 970 - хорошо, но "не то"
Flow Control всегда когда включал - приводил к замедлению, но попробую. В этот раз не пробовал.
Это команда на отключение. У
Это команда на отключение. У меня он переодически сходит с ума и замедляет всё адски. А его отключение не делает медленнее чем когда он не сошёл с ума.
Стандартно оно у меня
Стандартно оно у меня выключено: dev.ix.0.fc: 0
А что там с ssh/rsh/netcat ?
А что там с ssh/rsh/netcat ?
Надо кабели перетыкать,
Надо кабели перетыкать, поэтому не знаю.
Но не ожидаю чуда.
Те же 320Mb/sec.
Те же 320Mb/sec.
Вот что отдельно интересно в этой истории, чего я не понимаю пока:
ssh, 300Mb/sec, но 25k прерываний в секунду
samba - втрое выше скорость, в 10 раз меньше прерываний....
Размер пакета - нормальный, больше 8кб в среднем в обоих случаях.
Остановился пока на таком
Задирание окон приема/передачи и размера передаваемого блока для увеличения пропускной способности намекает на высокую latency при передаче. Что является причиной пока не ясно, пока подтверждена только пропускная способность оборудования. Я так понимаю explorer показывает меньше?
Эксплорер тоже 900+
Эксплорер тоже 900+
Латентность может быть не
Латентность может быть не (только) у оборудования, а у всего стека.
Как я тут уже выше написал, мне непонятна история с прерываниями:
ssh - 25k прерываний в секунду, чуть меньше чем "прерывание на пакет"
mbuffer - 80k, аналогичная история.
smbd - меньше трех тысяч. При этом пакетов в одну сторону: 900Mb/9k => 100k пакетов/сек. Т.е. 30 пакетов сворачиваются в одно прерывание? Или кто-то поллит?
При этом mbuffer я сегодня вот не щупал, а ssh/smbd - на одних настройках.
Да, ssh-ные 25k - это
Да, ssh-ные 25k - это несмотря на hw.ix.max_interrupt_rate
Латентность
Я имел ввиду весь стек прохождения, читаемого блока. А эксплорер молодец, выжимает всё что может :-). До прерываний я не доходил, пока не было нужды. Расчехлил свою линейку, может поможет найти кто тормозит.
11.1, samba 4.4, MTU 9000 (все сетевые настройки и настройки самбы по дефолту), win 10 (не помню, чтобы что-то тюнил).
diskspd -W0 -d20 -s -b4k -o1 I:\Test_64g
0 | 7923531776 | 1934456 | 377.83 | 96724.31 | I:\Test_64g (64GB)
Почти 97k IOPS. Теперь смотри сколько у тебя.
Завтра. Сегодня уже до
Завтра. Сегодня уже до мозолей доанонировал, работать надо ж еще.
Впрочем, старый ящик то под
Впрочем, старый ящик то под парами, можно и линейку.
0 | 12934684672 | 3157882 | 616.77 | 157892.62 | file64g.img (64GiB)
Ну и трафик похожий на измерения, 5Gbit/s примерно
Повторяемость разумная:
0 | 13108097024 | 3200219 | 625.04 | 160008.97 | file64g.img (64GiB)
Другой вопрос, что до
Другой вопрос, что до понимания ключей тестовой утилиты мне еще далеко. Почему -o16 приводит к резкому замедлению ?
А для -b512k - не приводит, наоборот приводит к ускорению
можно и линейку
Перечитал на свежую голову. Вчера не заметил, что 16MB окна не оказали решающего влияния. Но раз начали про сетевую задержку лучше лишний раз убедиться, что всё нормально. Я пользуюсь локально fio, но для единичной очереди сойдёт и dd.
dd if=/data/admin/test_64g of=/dev/zero bs=4k
68719476736 bytes transferred in 331.212954 secs (207478228 bytes/sec)
Зная локальную производительность и производительность по сети можем грубо оценить задержку которую вносит сеть при чтении 4к блоков. Мой файл забит нулями с lz4 сжатием и recordsize=128k.
Для контроля - единичная очередь для 128k блоков для моей линейки:
diskspd -W0 -d20 -s -b128k -o1 I:\Test_64g
0 | 16796483584 | 128147 | 800.93 | 6407.41 | I:\Test_64g (64GB)
dd if=/data/admin/test_64g of=/dev/zero bs=128k
68719476736 bytes transferred in 13.461554 secs (5104869350 bytes/sec)
Теперь о пропускной способности. Очередь которую мы задаем в diskspd позволяет разогнать и поддерживать окно передачи по сети для утилизации полосы пропускания. Для моей линейки ещё мало:
diskspd -W0 -d30 -s -b128k -o12 I:\Test_64g
0 | 36426481664 | 277912 | 1157.96 | 9263.71 | I:\Test_64g (64GB)
А вот наступает полная утилизация:
diskspd -W0 -d30 -s -b128k -o13 I:\Test_64g
0 | 36989042688 | 282204 | 1175.84 | 9406.71 | I:\Test_64g (64GB)
Можно грубо оценить достаточный размер окна. Дальнейшее увеличение глубины очереди не добавит производительности и будет упираться в полосу пропускания сети.
Про тюнинг самбы. Помню тоже переносил какие-то конфиги. Когда наступила пора разобраться всё убрал и с помощью testparm -v посмотрел, что там по умолчанию. Оказалось почти полностью совпадало с конфигом. Зачем писать лишнее? socket options точно отличался. Глянул в man smb4.conf, а там предостережение. Решил отдать всё на откуп системе. Как это повлияло на производительность уже не помню, но хуже точно не стало. С тюнингом сети была похожая ситуация. В очередной раз решил не копировать конфиг и по мере возникновения узких мест разбираться. У меня узкие места не возникали :-). Для моей линейки имею по умолчанию:
net.inet.tcp.sendbuf_max: 2097152
net.inet.tcp.sendbuf_inc: 8192
net.inet.tcp.sendbuf_auto: 1
net.inet.tcp.sendspace: 32768
net.inet.tcp.recvspace: 65536
net.inet.tcp.recvbuf_max: 2097152
net.inet.tcp.recvbuf_inc: 16384
net.inet.tcp.recvbuf_auto: 1
Все результаты получены с этими параметрами.
По поводу подозрений на win. Так как изменения произошли после корректировки на FreeBSD и конфиги были идентичны наверно стоит пока немного отложить подозрения на win.
Подозрения на win возникают в
Подозрения на win возникают в частности по той причине, что если по другому 10G интерфейсу на другой ящик идет что-то средней прожорливости (скажем, верификация бэкапа - пара гигабит полосы и занято одно ядро из четырех) - все упражнения с тестовой самбой проседают примерно на те же пару гигабит по полосе.
А в остальном - у меня процесс по запуску нового ящика в бой. Часть дисков переставить, а часть - вот переливаю, думаю что я развлечения с тестами по большей части закончил уже. А то мозоли ж.
> SO_RCVBUF=2097152
> SO_RCVBUF=2097152
Есть легенда что perfect prime number в качестве буфера приносит удачу.
33550336
https://www.mathsisfun.com/numbers/prime-numbers-advanced.html