[gosha-z 3]

37 minutes ago, syoma said:

когда инициализирует буффер,

tcpdump -s0?

 

P.S. У меня одного в голове молотом стучит термин "Закон Яровой"?

[_pv 79]

36 minutes ago, syoma said:

Тут есть одна проблема. Ожидается, что запись будет вестись в режиме 24/7/365 и у меня выходит примерно 60ТБ за день. Держать на диске много данных не надо - несколько часов максимум, но у SSD проблема - с такой скоростью перезаписи их ресурса хватает на 20 дней максимум... А если брать магнитные SSD, то надо будет RAID1 на 10 штук минимум, чтобы обеспечить такую пропускную способность. В общем, не пойму пока какой массив дешевле получается.  

45МБайт/с это меньше 4TБ в сутки, как получилось 60?

да и 100МБ/с и уж тем более 45, особенно при просто последовательной записи, обычные HDD и без raid вполне обеспечивают.

с временем жизни ssd тоже как-то странно, 4ТБ/сутки полностью перезапишут терабайтный SSD 4 раза за сутки, следовательно 20 дней == 80циклов перезаписи? пару порядков где-то потеряно, особенно если не брать всякие TLC/QLC/... где количество циклов перезаписи принесли в жертву ёмкости.

[syoma 1]

3 hours ago, gosha-z said:

tcpdump -s0?

Пробовал с этой опцией. У меня пакеты 850 байт. Оно ни на что не влияет.

3 hours ago, gosha-z said:

P.S. У меня одного в голове молотом стучит термин "Закон Яровой"?

Не понимаю о чем вы.

 

2 hours ago, _pv said:

45МБайт/с это меньше 4TБ в сутки, как получилось 60?

Я имел ввиду при трафике 700МБ/с. 45Мбайт уже не интересует, хочу больше, намного больше.

2 hours ago, _pv said:

с временем жизни ssd тоже как-то странно, 4ТБ/сутки полностью перезапишут терабайтный SSD 4 раза за сутки, следовательно 20 дней == 80циклов перезаписи? пару порядков где-то потеряно, особенно если не брать всякие TLC/QLC/... где количество циклов перезаписи принесли в жертву ёмкости.

В том-то и дело, что с 700Мбайт/c терабайтный SSD за сутки перезапишется  уже 60 раз, а один из самых навороченных Samsung 970 Evo Plus имеет только 1200 циклов перезаписи. То есть 20 дней и все.

Нашел у того же Samsung Enterprise-grade SSD. Те же PM1725b - но там все равно только 3 DWPD (полных перезаписи за сутки) при гарантии в 5 лет. При максимальной емкости в 12,8Тб мне надо будет 2штуки. И ценник там - можно упасть. Я не там ищу?

Quote

TLC/QLC/..

Я прекрасно понимаю что это, но в интернетах говорят, что этих вещей никто не производит. Если знаете, киньте ссылку на коммерческий SSD на 1-2ТБ с количеством циклов перезаписи ну хотя бы 10000.

[blackfin 31]

14 minutes ago, syoma said:

Я не там ищу?

Конечно, не там! :)

Вот в этот сервер можно воткнуть 6 Терабайт DDR4 памяти: HPE Proliant DL580 Gen10..

Только держитесь за что-нить, когда ценник увидите..

;)

[_pv 79]

ну раз в любом случае будет куча дисков, чтобы объёмы набрать, за скоростью ведь можно не гоняться, всё равно запись можно будет распараллелить, и соответствтенно вместо nmve со скоростью записи >ГБ/сек, взять обычных 8 х 8TB SATA HDD с 100МБ/с и в пару к$ уложиться.

SSD таких объёмов будет на порядок дороже, а от их скорости толку всё равно не сильно много.

 

 

16 x https://www.computeruniverse.net/en/buffalo-linkstation-210-4tb

1 x https://www.computeruniverse.net/en/netgear-gs324tp-100eus-24-port-smart-managed-pro-switch

 

 

 

[syoma 1]

В общем с >700МБайт/c какая-то проблема, или я что-то не догоняю.

Сетевуха на Intel 82599ES, машина - рабочая станция с двумя Xeonами и 64Гб памяти на Линуксе.  Создал ramdisk на 32Гб и пишу туда. dd пишет, что скорость записи на этот диск 4Гб/c.

У меня пакеты все одинаковые - размер 1476 байт (по Wiresharkу). ПЛИС выплевывает их со скоростью 558036 пакетов в секунду. То есть получается общий трафик 785Мбайт/c. Порт сетевухи подключен напрямую к выходу ПЛИС, но пробовал и через 10Гигабитный свич - те же грабли.

tcpdump теряет пакеты, зараза. То есть за секунду набегает всего 540-550 тысяч, не больше(статистику, что выводит tcpdump, я не очень догоняю, поэтому просто после записи открываю файлы в Wireshark и смотрю, сколько пакетов в секунду он показывает). При этом top показывает загрузку процессора 100%. Если уменьшать трафик, то загрузка с какого-то момента начинает уменьшаться и в итоге где-то на 600МБ/с потерь пакетов уже нет. Но мне надо больше и так происходит на всех моих машинах - такое впечатление, что где-то упираюсь во что-то.

Может быть можно что-то подшаманить? tcpdump вызывается с такими параметрами:

tcpdump -s 0 -B 2000000 -C 2000 -i enp137s0 -v -w /home/ubuntu/test/capture.pcap 

[RobFPGA 35]

Приветствую!

5 minutes ago, syoma said:

Может быть можно что-то подшаманить? tcpdump вызывается с такими параметрами:

Для начала может надо понять где потери идут  и подшаманить с  настройками сетевой с помощью ethtool.  

Удачи! Rob.

[Rst7 5]

Скорее всего у вас уже сам tcpdump - узкое горлышко. Пора писать собственный софт, для начала хотя бы просто recvfrom в бесконечном цикле. Оцените загрузку процессора. Потом будете пробовать запись на диск добавлять.

Ну или попробуйте поиграться с параметрами типа Interrupt moderation/Interrupt coalescing/etc

 

[k155la3 27]

1 hour ago, Rst7 said:

Скорее всего у вас уже сам tcpdump - узкое горлышко. . . . 

онож - утилита, инструмент, конечно, но неспециализированный. В основном консольный вывод, со всеми "вытекающими".

Если ТС имеет ввиду Ethernet-фрейм, то в tcpdump может быть много-чего лишнего, вроде определения TCP/UDP итп.

Wireshark вроде как с открытым кодом. Там посмотреть, возможно специализированные плагины есть.

Хотя более перспективно - написать свою утилиту на страницу-две кода для приема-записи raw фреймов. 

Прогнать ее сперва на "холостом" приеме (проверка на отсутствие потерь пакетов), затем отдельно - желательно с осциллографом - проверить что дисковая подсистема будет успевать записывать такой трафик. Затем - поженить оба куска кода.

Может быть еще ОС надо поднастроить на наиболее реалтайм режим.

IMHO.

[NStorm 0]

6 минут назад, k155la3 сказал:

Если ТС имеет ввиду Ethernet-фрейм, то в tcpdump может быть много-чего лишнего, вроде определения TCP/UDP итп.

Wireshark вроде как с открытым кодом. Там посмотреть, возможно специализированные плагины есть.

Да конечно (сарказм). Вы всё перепутали. tcpdump как раз таки без лишнего утилита. А Wireshark - графическая морда. Оба используют один и тот же pcap для захвата пакетов.

 

syoma,

 

есть вот что пара серверов с:

1c:00.0 Ethernet controller: Intel Corporation Ethernet Connection X722 for 10GBASE-T (rev 09)
1c:00.1 Ethernet controller: Intel Corporation Ethernet Connection X722 for 10GBASE-T (rev 09)
af:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01)
af:00.1 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01)

82599 подключены 2 линками в bonding к 10Г портам. Коммутаторы между собой связаны 2 x 40 Гбит линками. На серверах Intel NVMe P3520 правда, не самая новая и шустрая модель. Могу попробовать на днях с одного генерить трафик, на другом захватывать.

[NStorm 0]

Посмотрите еще вывод ethtool -k ethX

[Flood 13]

4 часа назад, RobFPGA сказал:

Для начала может надо понять где потери идут  и подшаманить с  настройками сетевой с помощью ethtool.  

Вы всегда очень авторитетно пишете на тему захвата пакетов, но никогда не даете никаких реальных деталей. Не сомневаюсь, что вы действительно успешно решали эту задачу, но сомневаюсь, что решением была одна-две строчки в ethtool.

А у вас с 10Гбит потоком справлялся однопоточный софт, или многопоточный с несколькими приемными очередями?

 

ethtool в случае однопоточного приложения почти ничем помочь не сможет - разве что увеличить размер приемных буферов сетевой карты до 4Кб и м.б. соптимизировать прерывания.

Для многопоточного случая в ethtool можно установить раздельные приемные очереди, но для этого нужно иметь несколько разных потоков на захвате.

 

Если tcpdump полностью загружает ядро, то наверное никакие настройки уже не помогут?

Если проблема не в полной загрузке, а в образовании задержек, то можно значительно увеличить размер буферов в ядре, например, до 32М:

sysctl -w net.core.rmem_default=33554432

sysctl -w net.core.rmem_max=67108864

Тогда у притупливающего tcpdump будет больше времени на разбор очередей (если не работает его собственная установка размера буфера). Но если он никогда не освобождается (ядро постоянно перегружено), то это не поможет. Если станет значительно лучше, но не совсем хорошо - увеличивайте до 128М и далее...

Проблема в захвате полного потока 10Гбит не в байтах в секунду, а в количестве пакетов в секунду - слишком много прерываний, сисколлов и переключений контекста. 

 

 

4 часа назад, syoma сказал:

Может быть можно что-то подшаманить? tcpdump вызывается с такими параметрами:

tcpdump -s 0 -B 2000000 -C 2000 -i enp137s0 -v -w /home/ubuntu/test/capture.pcap 

Параметр -v лучше выкинуть, хотя влияние не должно быть значительным.

И не уверен, что параметр -B работает как надо. Это может зависеть от конкретной системы.

[RobFPGA 35]

Приветствую!

23 minutes ago, Flood said:

Не сомневаюсь, что вы действительно успешно решали эту задачу, но сомневаюсь, что решением была одна-две строчки в ethtool.

А я и не говорил что решение было простое, да и было это уже несколько лет назад .  Но IMHO, решение конкретной проблемы надо всегда начинается с понятия источника проблемы - в данном случае со сбора статистики  по сетевой и стеку  и ее анализа. 

А так я могу только гадать согласится с вашим предположением что  проблема скорее всего  в  числе прерываний  соответственно  надо  подшаманить настройки политики interrupt coalescing  для сетевой  увеличив по возможности минимальный интервал (ethtool rx-usecs ..., tx-usecs ...). Или  попробовать   сменить политику  привязки прерывание к CPU,  попробовать распределить  обработку IRQ на разные  ядра.  Или еще что но что именно понятно будет только поиграв параметрами и посмотрев на изменения результатов. 

Удачи! Rob.

[NStorm 0]

[SUM] 0.00-5.00 sec  4.88 GBytes  8.39 Gbits/sec  3566680/6   713306 pps
[SUM] Sent 3566680 datagrams

# tcpdump -s 0 -B 2000000 -C 2000 -i bond0 -v -w /tmp/capture.pcap
Got 3567359
3567688 packets captured
3567718 packets received by filter
0 packets dropped by kernel
1 packet dropped by interface

# ls -lh
total 5.1G
-rw-r--r-- 1 root root 1.9G May 12 23:45 capture.pcap
-rw-r--r-- 1 root root 1.9G May 12 23:45 capture.pcap1
-rw-r--r-- 1 root root 1.4G May 12 23:45 capture.pcap2

На 12 Гбитах есть потери:

[SUM] 0.00-5.00 sec  7.32 GBytes  12.6 Gbits/sec  5350026/6  1069951 pps
[SUM] Sent 5350026 datagrams
...
5350952 packets received by filter
905918 packets dropped by kernel
2 packets dropped by interface

PS: Процы 2x Intel(R) Xeon(R) Gold 6130

Изменено 12 мая, 2020 пользователем NStorm

[syoma 1]

Ухты, какая живая дискуссия получилась. Спасибо за участие!

Попытаюсь ответить свои пять копеек. Сразу скажу, что в Линуксе не силен.

Quote

Ну или попробуйте поиграться с параметрами типа Interrupt moderation/Interrupt coalescing/etc

Интересно, что тут можно подкрутить. У меня сейчас примерно 600 тысяч пакетов в секунду. По современным меркам это не так уж и много, вроде.

18 hours ago, k155la3 said:

Прогнать ее сперва на "холостом" приеме (проверка на отсутствие потерь пакетов), затем отдельно - желательно с осциллографом - проверить что дисковая подсистема будет успевать записывать такой трафик. Затем - поженить оба куска кода. 

Чтобы исключить влияние дисковой подсистемы, я пишу на RAM disk. Там скорость записи грандиозная - больше 2Гб/c, и в некоторых машинах намерял аж 4 ГБ/с поэтому вряд-ли тут будет Bottleneck. Я пишу файлами по 2 ГБ и в бакгрануте каждую секунду запускается скрипт, который проверяет размер файлов и удаляет самые старые. Вот когда это заработает, можно начать проверять дисковую подсистему. 

18 hours ago, k155la3 said:

Может быть еще ОС надо поднастроить на наиболее реалтайм режим.

Я не очень понимаю причем здесь риал-тайм. Тут как раз система должна быть настроена на больший throughtput, а не на отклик. Если она будет обрабатывать прерывания не по одиночке, а пачками, то это не реалтайм вообще и latency может быть огромной, но с точки зрения производительности, это как раз самый оптимальный вариант, если конечно, интеррапты не пропадают. 

Вопрос собственно - как это узнать? Где можно узнать, успевает система обработать все прерывания, или нет?

15 hours ago, Flood said:

А у вас с 10Гбит потоком справлялся однопоточный софт, или многопоточный с несколькими приемными очередями?

ethtool в случае однопоточного приложения почти ничем помочь не сможет - разве что увеличить размер приемных буферов сетевой карты до 4Кб и м.б. соптимизировать прерывания. 

Дело в том, что я пока вообще не в курсе как оно у меня работает - одним потоком, или несколько, ХЗ. Знаю только модель сетевухи, версию Линукса - это Ubuntu последняя, да железо - не новая рабочая станция с двумя 6-ядерными процессорами Xeon и дофигищей вентиляторов. Скажите, как увеличить буфера и оптимизировать прерывания и я обязательно попробую и отпишусь.

15 hours ago, Flood said:

Если проблема не в полной загрузке, а в образовании задержек, то можно значительно увеличить размер буферов в ядре, например, до 32М:

sysctl -w net.core.rmem_default=33554432

sysctl -w net.core.rmem_max=67108864

Тогда у притупливающего tcpdump будет больше времени на разбор очередей (если не работает его собственная установка размера буфера). Но если он никогда не освобождается (ядро постоянно перегружено), то это не поможет. Если станет значительно лучше, но не совсем хорошо - увеличивайте до 128М и далее...

Вот тут прикол в том, что -B в TCPDump как-то непонятно работает. Т.е. я не смог понять, как размер буфера коррелирует с потерей пакетов. Знаю только, что чем больше буфер, тем дольше tcpdump его инициализирует на старте, но потом, что при маленьком буфере, что при большом, потери +- одинаковые. Опцию попробую.

15 hours ago, Flood said:

Проблема в захвате полного потока 10Гбит не в байтах в секунду, а в количестве пакетов в секунду - слишком много прерываний, сисколлов и переключений контекста. 

Выше отписался, думаю, что у меня не так много пакетов.

Прикол в том, что изначально я пробовал с уменьшенной длиной фрейма - 768 Байт, но с двойной плотностью пакетов, то есть их было примерно 1 200 000 - 1 400 000 в секунду. И TCPdump с упорством пъяного все равно терял 2-3% от них. Т.е. тут как-то не получается логика - выходит tcpdump может переваривать и больше пакетов в секунду, чем у меня сейчас, но они должны быть намного короче?

15 hours ago, RobFPGA said:

Но IMHO, решение конкретной проблемы надо всегда начинается с понятия источника проблемы - в данном случае со сбора статистики  по сетевой и стеку  и ее анализа. 

Подскажите куда смотреть. Как я уже написал TCPdump выводит какую-то фигню - может потому, что у меня Broadcast трафик, а не UDP. Если TCPdump не запущен, сетевуха вообще эти пакеты отбрасывает.