А что, отец, люди которые даже бесплатные статические анализаторы не используют в вашем городе есть? Тот же clang-check от совсем глупых ошибок вроде неплохо спасает.
По-сути, тот же FAQ, только озвучиваемый живым человеком.
И это правильно, только вместо FAQ должна быть проблемно-ориентированная документация, а ответ на любой вопрос, перед тем как попасть к клиенту должен появиться в ней. После этого ответ можно зачитать клиенту. :)
Это вы верно сказали. ± универсальные вещи от которых вряд ли будет хуже (RSS/RPS/XPS) я попытался в код завернуть недавно, думал о том, как бы всё это сделать ещё более out-of-box, чтобы человеческий мозг вообще не напрягать (потому что когда он напрягается он порой делает всё ещё хуже), но всегда находится какой-нибудь кейс в котором всё будет неидеально :(
Пардон, попутал с Receive Flow Hash Indirectiction.
Да, RFS уместен, в случае если кто-то в userspace пакетики получает, но в случае форварда это, как мне кажется только лишний оверхед (прыжок пакета в Flow Table).
Не, вы правы конечно, если прибить запуск юзерспэйс приложений на ядра не занимающиеся обработкой пакетов — профит будет, но в случае если это тупая молотилка трафика (в основном такими занимаюсь, небольшая профессиональная деформация) — то вряд ли.
Про RFS — тут опять же надо вклиниваться в процесс запуска приложения, которое должно определенный сорт трафика потреблять, а не только выполнить правильную команду для ethtool. Что-то универсальное для этого запилить сложновато. Хотя, если есть идеи — welcome to the github issues, я бы с удовольствием сделал.
По дефолту он скрывает строки, в которых все прерывания подрастают меньше, чем на 80 в секунду. Его цель показать то, что несет большую часть нагрузки на ядра процессора/выявлять шторм прерываний. Можете использовать: network-top -l 0
пришёл к тому что нужно пилить тулзу которая работает со списком сетевых карт, но в итоге отложил на далёкое потом, т.к. она должна учитывать очень много факторов, которые сильно варьируются в зависимости от времени (рейт прерываний, типы очередей, объёмы трафика, суммарные ресурсы сервера) и это сложно.
Удалил
А что, отец, люди которые даже бесплатные статические анализаторы не используют в вашем городе есть? Тот же clang-check от совсем глупых ошибок вроде неплохо спасает.
Расскажите про автоматический рефакторинг в Vim (и сколько он с таким обвесом плагинами ест памяти).
[удалил]
И это правильно, только вместо FAQ должна быть проблемно-ориентированная документация, а ответ на любой вопрос, перед тем как попасть к клиенту должен появиться в ней. После этого ответ можно зачитать клиенту. :)
Я бы был очень благодарен за разметку пунктов, как элементов списка. Читать тяжеловато.
Это вы верно сказали. ± универсальные вещи от которых вряд ли будет хуже (RSS/RPS/XPS) я попытался в код завернуть недавно, думал о том, как бы всё это сделать ещё более out-of-box, чтобы человеческий мозг вообще не напрягать (потому что когда он напрягается он порой делает всё ещё хуже), но всегда находится какой-нибудь кейс в котором всё будет неидеально :(
Случайно продублировал вот этот комментарий ниже
Про XPS: добавил тулзу autoxps в версии 2.2.5
А, помню такое. 4к прерываний на ядро вроде как слишком уж жёсткий лимит выходит в итоге.
Пардон, попутал с Receive Flow Hash Indirectiction.
Да, RFS уместен, в случае если кто-то в userspace пакетики получает, но в случае форварда это, как мне кажется только лишний оверхед (прыжок пакета в Flow Table).
Спасибо!
Увы, не использовал, трафик обычно — зеркало со свитчей.
Кстати, что за магия такая, что у вас все сетёвки генерят абсолютно одинаковое число прерываний?
--device-regex вам в помощь, чтобы от vlan'ов с ума не сходить :)
32 битная система, полагаю?
Не, вы правы конечно, если прибить запуск юзерспэйс приложений на ядра не занимающиеся обработкой пакетов — профит будет, но в случае если это тупая молотилка трафика (в основном такими занимаюсь, небольшая профессиональная деформация) — то вряд ли.
Про RFS — тут опять же надо вклиниваться в процесс запуска приложения, которое должно определенный сорт трафика потреблять, а не только выполнить правильную команду для ethtool. Что-то универсальное для этого запилить сложновато. Хотя, если есть идеи — welcome to the github issues, я бы с удовольствием сделал.
По дефолту он скрывает строки, в которых все прерывания подрастают меньше, чем на 80 в секунду. Его цель показать то, что несет большую часть нагрузки на ядра процессора/выявлять шторм прерываний. Можете использовать:
network-top -l 0Fixed! https://github.com/strizhechenko/netutils-linux/issues/102
Если в 2.0.8 повторяется, можете скинуть вывод
lscpu -p?А, понял. Там логика для раздельных RX и TX очередей следующая:
Собственно это он и делает, а поскольку RX очередь одна и TX очередь одна — обе очереди падают на 0 ядро.
В феврале ещё думал как лучше поступать в этом кейсе:
https://github.com/strizhechenko/netutils-linux/issues/8
пришёл к тому что нужно пилить тулзу которая работает со списком сетевых карт, но в итоге отложил на далёкое потом, т.к. она должна учитывать очень много факторов, которые сильно варьируются в зависимости от времени (рейт прерываний, типы очередей, объёмы трафика, суммарные ресурсы сервера) и это сложно.