CHR Загрузка одного ядра в 100%

[Erik_U]

А с физикой все в порядке?

На интерфейсе в сторону оператора (физичесоком) ошибки, дропы есть?
Утилизация канала какая в сторону оператора?

Проблема 100% перманентная? Или возникает периодически?
С другими процессами взаимосвязи не прослеживается?

[rst161]

/ip/firewall/mangle> add chain=forward

почему форвард? Ограничиваете какой-то транзит, чтобы он не мешал работе ОВПН ?

Мне кажется, что проблема больше "косметическая".
Неравномерная загрузка ядер это же не полная загрузка всех ядер. После полной загрузки первого, новые процессы запускаются на следующем.
У вас же процессы не зависают.

Проблема точно нуждается в решении?

Интересно, но после вчерашнего запина. После ребута. Как будто отпустило CHR... Вроде загрузка проца стала меньше, не на много но на два- три процента, но стало проще. И ни разу со вчерашнего дня не было повышения. При этом трафик как гулял так и гуляет.
А что вас сподвигло подумать что проблема именно в очереди а не в чем-то другом ?

[rst161]

А с физикой все в порядке?

На интерфейсе в сторону оператора (физичесоком) ошибки, дропы есть?
Утилизация канала какая в сторону оператора?

Проблема 100% перманентная? Или возникает периодически?
С другими процессами взаимосвязи не прослеживается?

С физикой точно всё в порядке со стороны сервера и chr. Её не много. Коммутировано все на седьмой категории заводских, покупных патчкордах. ( почти нахаляву достались... По цене пятерки)) Там топология проста . На входе стоит 5009. в нём gpon и на нём же (5009) поднят pppoe провайдерский. На нём нет ничего кроме bonding 802.3ad с chr. 802.3ad ( и то сейчас его нет) два патчкорда в chr. в него гуляет трафик наружу. Один патчкорд под ipmi,один патчкорд esxi. из физики всё. на выходе к оператору pppoe максимум 100-150 мегабит, если ничего не качается.
Ошибок на порту нет


Проблема плавущая. Но с периодичностью, обычно раз в сутки вылезает. Как ранее было сказано. Сейчас как будто стало проще, но может и придумываю себе. так же как и было в среднем при нормальной работе 20% загрузки. Но при этом теперь чаще вижу значение в 10-14%
До последнего зависания добавил вот этих три правила. Причем, если честно до конца не понимаю в чем разница между 0 и 1.

0 chain=forward action=change-mss new-mss=clamp-to-pmtu passthrough=yes tcp-flags=syn protocol=tcp out-interface=all-ppp log=no log-prefix=""

1 chain=forward action=change-mss new-mss=1360 tcp-flags=syn protocol=tcp tcp-mss=1453-65535

2 chain=output action=mark-packet new-packet-mark=trassir-tcp passthrough=yes protocol=tcp log=no log-prefix=""

А плавущая проблема только потому что не разу она не вылезала при мне, когда хотел бы её вызвать. Пробовал вызывать. Не многими способами. Резкими обрывом интернета. Резкое включение-отключение ovpn client-ов. загрузкой спидтестом, bttest-ом в обе стороны одновременно с кем нибудь из клиентов. Как по внешнему адресу, так и по туннельному. со стороны chr bt test до белого адреса клиента. Со стороны клиента по туннельному адресу до снр. и в добавок iperf с спидтестом уже с самого трассира. И эта падла продолжала работать. Но стоит отключиться на час-два. Заходишь и вот здравствуйте снова. Опять же повторюсь всегда висло ядро по ssl вчера в первые в чем-то другом. Единственное после добавления правил я не перегружал СНР. Правила применяются в режиме реального времени ?

[Erik_U]

С очередями это ваша идея.
Правила применяются без перезагрузки. Видно по счетчику пакетов.

[rst161]

А с физикой все в порядке?

На интерфейсе в сторону оператора (физичесоком) ошибки, дропы есть?
Утилизация канала какая в сторону оператора?

Проблема 100% перманентная? Или возникает периодически?
С другими процессами взаимосвязи не прослеживается?

Не долго музыка играла. Вот и вернулись мои 100%
Теперь уже при мне. Как сглазил... За то точно знаю в какой момент. В момент импорта ovpnclient-а. Выгрузил файл конфигурации с другого микрота. На СНР импортирую. Сходу загрузка проца прыгает до 30 процентов. Полез в профайл. Привет 100% ssl на одно ядро

[rst161]

С очередями это ваша идея.
Правила применяются без перезагрузки. Видно по счетчику пакетов.

Да, так и думал. в любом случае история повторилась. Очень жаль. Есть идеи куда еще посмотреть можно ?

[Erik_U]

попробуйте wireguard.
он менее ресурсоемкий.

На всякий случай все таки спрошу. System-resources-hardware галочка стоит?

[rst161]

Про эту галку идёт речь? Если да, то стоит.

Есть нюанс. После вчерашнего добавление нового овпн клиента СНР стало намного хуже...

[rst161]

Спасибо всем тем кто пытался помочь. Тему думаю можно закрывать.
В общем я не нашел решения. А Т.П микротик молчит.

Мною было замечено что при использовании пароля выше 193 бит. Не важно СНР выступает в качестве сервера или клиента овпн. ССЛ загрузкой на ядро прыгает до 100% в течении первых часов. Если же использовать пароль более короткий, допустим до шести символов, то загрузка ЦП могла не подниматься несколько дней спокойно. Но это был вопрос времени. В данном конкретном случае, я сдался и перевёл всё на wireguard. Загрузка ЦП уже как неделю выше 10% не поднимается. Склоняюсь, к тому что у меня что-то с железом. Есть у меня съемный ВПС с СНР, там опенвпн клиентов в разы больше чем здесь. Настройка одинаковая что на проблемном, что на съемном. Правда разница есть. Трафика на съемном гуляет в разы меньше.... В общем всем спасибо за внимание.