понт, 120-150к

это тотал, ин и аут. до этого strace гонялся, по pid процесса раздающего и принимающего, не на дебаг ядре, так там времени много тратится write и мало на read

там по одному из тредов я стрейсил. было 8 сокетов с которых читались данные и 8 которые читали, репрокси такое себе

strace сильно меняет поведение системы, его для такого использовать нельзя. В perf есть свой strace -c

и по каждому fd выше я агрегировал за секунду время проведенное в write сисколе. а вот график переданных данных по каждому fd за это время

ну и предполдожил, что деградация из-за приницпа strace наблюдается существенная. потому перешел на perf

вот топ swapper, в одном случае это EC2, в другом свои сервера с OpenVZ ядром

https://i.stack.imgur.com/XdnBT.png

https://i.stack.imgur.com/BCtil.png

ну и перекос огромный. подозревая что debug ядро на Linux AMI 2017.09 отличается в чем-то от vzkernel7-debug, потому что на последнем куча save_stack, dump_trace и тп сисколов. могу предположить, что именно из-за этих медленных сисколов я вижу такой разброс

но почему их нет на AMI - непонятно

ну и разгружен EC2 инстанс был больше при меньшей вычислительной мощности

Напомните что за swapper

раньше назывался процесс init, это scheduler походу и ранер остальных процессов

так-то он в idle должен торчать, либо реагировать на softirq от девайсов, в моем случае от NIC

Это что то openvz специфичное? В любом случае много ack можно подкрутить tcp_delack_min

Чтобы слать пореже

но не только в нем грабли. любой процесс что делат write в сетевой fd приводит к вызову tcp_write_xmit и начинает тупить

накиньте памяти сокетам

тюнилось ядро

sysctl что то там wmem

и там настройки что при аналогичных ситуациях тянули по 20гбит трафика

дада, wmem, mem, rmem - это первым делом

еще до perf, по признакам проявляемым - безрезультатно, как и тюнинг TSO/MSO и смена карточки

ибо был Broadcom 5720, а воткнули X540 для теста

никакой разницы

Ну отправка пакетов при write это нормально.

Вы сейчас сколько прокачиваете?

все те же грабли с медленным write, на уровне сискола, а дальше perf по цепочке показывает на уровне кода драйвера. код драйвера читал тоже, на предмет проблем с DMA, но ничего не нашел. заткнулся на том что не знаю особенностей работы с perf и почему save_stack колится

100ин, 200аут на этих железках. максимум 1 гбит возможен на этом конфиге, но с проблемами латенси и большим разбросом

сейчас на 10г карте живем

т.е. ядро намного раньше упирается. бтв, не в контейнере гоняли эксперименты, просто на vzkernel7

save_stack это точно не артифакт perf?

Если нет, мож оно в dmesg срет стактрейсами :)

вот не знаю артефакт ли. по работе perf не так много инфы

в vger.kernel.org по листу perf написал, но он полудохлый

вот не знаю артефакт ли. по работе perf не так много инфы

Если артефакт, то наверху всех флеймов он будет

Если он только в kfree вызовах то это не артефаки

бтв, про delack, в коде сишном запись в сокет с TCP_NODELAY, потому Нагель выключен

так что не должно быть tcp ack delay в принципе

бтв, про delack, в коде сишном запись в сокет с TCP_NODELAY, потому Нагель выключен

Епт, а что ж вы хотите тогда ) сами просите слать пакет на каждый write

Это я про tcp_no delay. Delack он вроде на принимающей стороне

save_stack все равно подозрительно

а использовал кто dm-integrity/dm-raid?

https://i.stack.imgur.com/BCtil.png

Похоже артефакт перф. Но на предыдущей нет этого save_stack. Может флаги какие нибудь нещадящие использовались?

лучше скажите, а в какой версии был? в 3.0 и 2.1 зукипера тоже вроде не было. И как я понимаю дизайн кассандры - он там и не нужен

в 1.x вроде какой-то

Похоже артефакт перф. Но на предыдущей нет этого save_stack. Может флаги какие нибудь нещадящие использовались?

вот я тоже не знаю так ли это. почему-то в других сисколах, не касающихся сетевой активности, sace_stack отсутсвует

есть flame graph полный в svg, если интересно

https://i.stack.imgur.com/XdnBT.png

у тебя тут xen в топе

есть flame graph полный в svg, если интересно

кидай без дебага )

там xennet_start_xmit, а на графие другом на его месте будет bnx2_start_xmit

это кол функции драйвера NIC

https://www.dropbox.com/s/gh0uxltxa1ws0ir/ec2_all_processes.svg?dl=0 - EC2 - all processes

https://www.dropbox.com/s/n2g2cywakhl58mb/vzkernel7_all_processes.svg?dl=0 - Our system all processes

детализация по swapper, net_rx_action

https://www.dropbox.com/s/td37qi9h7jdlrod/ec2_all_processes_net_rx_action.png?dl=0 - EC2

https://www.dropbox.com/s/olki993iby2gigp/vzkernel7_all_processes_net_rx_action.png?dl=0 - our system

вот я тоже не знаю так ли это. почему-то в других сисколах, не касающихся сетевой активности, sace_stack отсутсвует

Слушайте, а может у вас через старый kprobe/ftrace что то подцеплено и мониторит вызовы?

Там в /sys были какие то невменяемые крутилки как раз для такого. Там была опция трейсить определенные вызовы и как раз собирать стэки

я тоже так думал, но по flamegraph есть взовы что не закачниваются стек трейсами, а значит они эпизодические и провялются только в нетворкинг подсистеме

если бы только сеттингс ядра, то было бы на каждом коле такое имхо

Коллеги, а может есть тематичный канал по Hadoop?

https://t.me/hadoopusers

sps

я тоже так думал, но по flamegraph есть взовы что не закачниваются стек трейсами, а значит они эпизодические и провялются только в нетворкинг подсистеме

В том то и дело, что через ftrace можно выбрать откуда стэктрейсы снимать.

https://pbs.twimg.com/media/DTsNw7QWkAAqOIU.jpg:large

я бы не беспокоил покой чатика, если бы не имя автора

Уже было, вроде

я бы не беспокоил покой чатика, если бы не имя автора

:'(

Вот если б послушать 😊

В исполнении?

лепса конечно

а 12-ую что бы бритни спирса

Это в чяте хенгопса родилось btw

дорогие товарищи, а есть ли у кого на примете ubuntu/debian докерфайлы с systemd, нужно для автотестов

Это в чяте хенгопса родилось btw

а что за чат? где такой?

в слеке есть hangops.slack.com