Свежие комментарии

> если на принимающей стороне увеличить bs у dd, результат не меняется

Зато будет виднее, кто жрёт CPU, а кто нет.

> Может быть тупо большой tcp buffer и не скейлить его.

mbuffer, судя по его сорцам, по умолчанию ставит размер приёмного буфера в 1 мегабайт (TCP RWIN), а rsh использует системный дефолт:

$ sysctl net.inet.tcp | fgrep recv
net.inet.tcp.recvspace: 65536
net.inet.tcp.recvbuf_max: 2097152
net.inet.tcp.recvbuf_inc: 16384
net.inet.tcp.recvbuf_auto: 1

Вероятно, автоскейлинг тупо не успевает разогнать. Можно попробовать либо поднять первоначальное значение net.inet.tcp.recvspace сразу до мегабайта, либо резко увеличить инкремент net.inet.tcp.recvbuf_inc

Я что хочу сказать
1) когда я фигачу ssh (360Mb/sec)/rsh (до 330) - я вижу ~40k прерываний в секунду. Типа, много.
если на принимающей стороне увеличить bs у dd, результат не меняется
2) Дальше беру mbuffer:
Sender:
dd if=/dev/zero bs=1M count=50000 | mbuffer -4 -O 10.5.0.3:3333 -s 64k -m 64m
in @ 1180 MiB/s, out @ 1180 MiB/s, 48.3 GiB total, buffer 100% full50000+0 records in
50000+0 records out
52428800000 bytes transferred in 42.463043 secs (1234692477 bytes/sec)

Receiver:
mbuffer -4 -I 3333 -s 64k -m 64m -o /dev/null
in @ 1180 MiB/s, out @ 1180 MiB/s, 48.3 GiB total, buffer 0% full
summary: 48.8 GiByte in 42.5sec - average of 1176 MiB/s

Прерываний 75-85k в секунду.

Теперь уж netcat, раз его все советуют:
dd if=/dev/zero bs=1M count=50000 | nc 10.5.0.3 3333
50000+0 records in
50000+0 records out
52428800000 bytes transferred in 82.591318 secs (634797954 bytes/sec)

mbuffer быстрее.

Из чего я делаю вывод, что дело не в настройках собственно сетевого интерфейса ix (сетевая карта на sender Intel X540, на принимающей Ethernet Connection X553/X557-AT 10GBASE-T, обе 10G). Возможно interrupt moderation помог бы немного, но для 9k-пакетов там количество пакетов на самом деле не очень большое.

Дело, как я думаю, в настройках tcp. Что-то такое mbuffer умеет, чего ssh/rsh не умеют. Может быть тупо большой tcp buffer и не скейлить его.

Это на принимающей стороне HPN, на передающей - обычный, сейчас попробую HPN patches применить еще.

У меня узкое место - на принимающей стороне.

Вот типичная картина (скриншоты проще получаются в png, пардон)
top на sender: https://www.dropbox.com/s/3issenlt4x833ah/top-rsh-send.png?dl=0
top на receiver: https://www.dropbox.com/s/1r6fva7876mekxf/top-rsh-recv.png?dl=0

На sender делаю так:
# dd if=/dev/zero bs=1M count=10000 | rsh 10.5.0.3 dd of=/dev/null
10000+0 records in
10000+0 records out
10485760000 bytes transferred in 33.885600 secs (309445904 bytes/sec)
20475234+8465 records in
20480000+0 records out
10485760000 bytes transferred in 33.756500 secs (310629359 bytes/sec)

Конечно, не только в dd. Узкое место наверняка CPU, а dd bs=1G только усугубляет проблему, создавая немалый дополнительный вклад в загрузку CPU драйвером /dev/zero, что никак не помогает вычленить основную неоптимизированную подсистему, чтобы её оптимизировать :-)

Прежде чем начинать тюнить - надо определить узкое место. И раз rsh тоже тормозит (а это голый TCP-сокет), то узкое место наверняка не (только) в ssh.

Скорость тут достаточная, потому что не приходится параллельно тратить CPU на обслуживание сетевых прерываний и CPU хватает. А когда сеть тоже хочет CPU - картина будет другая.

Тут такая история
1) ssh (и с шифрованием и без) работает быстрее rsh
2) mbuffer - mbuffer выжирает нормально почти всю полосу, ну там не 10 гигабит а 8, мне достаточно.

Проблема в том, что мне нужен именно remote shell, чтобы ошибки с удаленного конца ловить.

То есть конечно, если rsh починить не получится, придется mbuffer - mbuffer или netcat, но не хотелось бы

> что бы такое потюнить (у ssh, openssh-portable, rsh
Лучше исключить ssh из цепочки пересылки данных, даже с выключенным шифрованием.
Замена mbuffer на nc (netcat) на обеих концах может ощутимо поднять скорость. Были прецеденты.

Тоже были такие мысли :-). Можно выключить префетч, быстро полностью затарить нужные файлы в L2ARC, а затем включить префетч. Думал даже сделать это автоматом при загрузке. Где-то год назад в одном месте стояла подобная задача и нужно было сделать - "что бы летало". Поэтому пришлось вникнуть, что бы заставить "работать как надо". В результате после первого чтения имел скорость nvme (около 1,7GB/s). Затем, после того как заметил, что метаданные сжимаются где-то в 25 раз, сообразил, что в данной схеме можно ещё настроить и жёсткую пирамиду - самые востребованные данные читаются только из ARC, менее востребованные из L2ARC, остальные из основного пула. Отстроил и это. И ... упёрся в латентность сети :-). Оказалось проще и эффективней для той задачи переместить нужные для работы каталоги на локальный nvme.

"Тотальное" кеширование противоречит заявленной "The main role of this cache is to boost the performance of random read workloads." И сам механизм сканирования хвоста арка для такого "тотального" кеширования не очень подходит. Для хорошего эффекта нужно рассчитывать время, глубину сканирования, учитывать производительность основного пула и ssd. Наверно это не для универсального продукта. Только для специфических задач.

если сделать prefetch disable, то все очень медленно.

Вообще, вы бы порепортили в FreeBSD, раз уж в это место влезли и разобрались?

Если сделать vfs.zfs.prefetch_disable=1 и подобрать параметры сканирования/записи в L2ARC, то данные могут закешироваться даже после первого-второго чтения, причем в последующем чтение с hdd будет полностью отсутствовать. Что бы была понятна причина - в одной из ветвей после предварительного чтения и последующего результативного чтения в созданной структуре для арка не устанавливается ARC_FLAG_L2CACHE и при сканировании данная запись не может попасть в L2ARC. Попадание в это ответвление зависит - было ли на момент результативного чтения предварительное чтение завершено или нет.

Прочитал эти же файлы еще два раза (всего, значит, четыре). Размер набора файлов - 50G, в L2 легло 46G (до начала - было занято 60, сейчас 106). Читаем в пятый раз:

# zpool iostat -v zdata 5 | grep diskid/DISK-C6EF076A07E100005289
  diskid/DISK-C6EF076A07E100005289   106G   341G      1      1  1,26M  1,68M
  diskid/DISK-C6EF076A07E100005289   106G   341G    180      0   156M   204K
  diskid/DISK-C6EF076A07E100005289   106G   341G    802      6   793M  6,76M
  diskid/DISK-C6EF076A07E100005289   106G   341G  1,07K     49  1,06G  49,1M
  diskid/DISK-C6EF076A07E100005289   107G   340G    802     74   799M  74,5M
  diskid/DISK-C6EF076A07E100005289   107G   340G    557     32   555M  32,5M
  diskid/DISK-C6EF076A07E100005289   107G   340G    691     13   689M  13,6M
  diskid/DISK-C6EF076A07E100005289   107G   340G    895     38   892M  38,1M
  diskid/DISK-C6EF076A07E100005289   108G   339G     20    214  19,1M   214M
  diskid/DISK-C6EF076A07E100005289   108G   339G      0      8      0  8,57M

О чем я, собственно, и говорю: L2 набирается, но сильно постепенно, вот за пять чтений набора файлов (путем tar cvf /dev/null .) где-то процентов 90 куда надо легло.