![[Home]](/static/root.gif)
Вдобавок в вот этому узрел вдруг всплеск очереди на почтовом сервере, примерно вот такой:
megaprovider ~ # mailq|grep psv@icf.bofh.ru|wc -l 4667 megaprovider ~ #
А там консервный завод в сторону яхи хотмейлов итд.
Все оказалось просто, акаунт дохлый, чувак им не пользуется уже хер знает скока, и ктото решил проявить свою гениальность и влепить на акаунт пароль 12345, ведь никто же не подумает что в интернете могут быть дебилы с таким паролем😊 А наши любимые боты не дремлют, взяли и попробовали, и у них получилось😊
Пришла и третья беда, вечером позвонили и сообщили что на NAT'ах чтото все очень-очень плохо, softirq грузит процы в сотку.
Посмотрел - с части интерфейсов прерывания действительно ушатывают некоторые ядра, траффик вырос гдето в 3 раза с тех пор как их поставили. NAT тоже поменялся - привернули лимит трансляций per IP, и стали натить в пул адресов а не в 1, а это же все тоже не бесплатно в плане ресурсов CPU.
Позвонил Главный инженер, как всегда не вовремя подруку, но это ладно, волнуеца же😊 Поинтересовался как дела, заодно сообщил что оно так уже давно делает периодически в часы пиковой нагрузки. Но все сидят ждут чегото, хз чего, может думают что когда они подключают больше клиентов у них траффик нихуя не растет а только падает.
При таком раскладе ушатали и резерв, так как если запаса по производительности нет то и резерва тоже, нагрузка то при отказе ляжет на оставшиеся сервера, не способные ее обработать. Поэтому деградация сервиса будет такая что можно сказать что резерва нет.
Я это раньше мониторил посредством smokeping, он сразу резво так вякает если растет rtt или не дай боже гдето чтото теряется, тоесть еще за долго до того как ситуация превратица в катастрофу. Но блять с этими переездами сервер где он был вывели из эксплуатации и там ад и израиль и вобщем средств мониторинга у меня не осталось. А нового пока нет. Башка забита перестройкой ядра сети, серверной и инфраструктуры вцелом, и я туда и не смотрел сполгода как совсем. Я строю, другие эксплуатируют, то что я понастрою. До победного конца как оказалось.
Начал смотреть что можно сделать прям сейчас, оказалось что softirq по цене нихрена не одинаков в случае NAT'а, он же в softirq обрабатывается. Входящие на NAT из вне пакеты требуют значительно больше ресурсов для обработки нежели приходящие со стороны серых подсетей.
Прерывания были размазаны поровну исходя из количества сетеух, очередей на них и количества процессоров. Тоесть там впринципе 4 нагруженных интерфейса в бондинге, 2 ввех 2 вниз, и 12 процов, соответственно по 3 irq на интерфейс. Такая схема хорошо работает на чисто маршрутизаторах, там прерывания равноценны. Но не при наличии NAT'а. Некоторые из прерываний с интерфейсов смотрящих вверх грузили свои CPU в полку.
Так же понятно то что как бы чем меньше очередей на интерфейсе тем больший траффик в каждую конкретную очередь влетит, тем больше нада ресурсов чтоп отработать прерывание от этой очереди. Ну и размазываца траффик по ним он будет менее равномерно скорее всего.
Так и получалось - 1 очередь перегружена, 2 других сильно не догружены.
Решил увеличить количество irq и очередей соответственно тоже, но оказалось что BCM5720 больше 4 не умеют, до этого выставлено было 3, но тем не менее полегчало, процентов на 20-30.
Но тоже не без факапа - сервер наебнулся при изменении количества очередей на лету, ну точнее не то чтоп наебнулся совсем, драйвер выдал какой то splat экрана на 4 частично в хексе, после чего линки на интерфейсах начали то падать то поднимаца, видимо под нагрузкой чтото у него там не срослось. Рассматривать мне его было некогда поэтому выход 1 - перезагрузка.
Перегрузил, второй NAT сервир как то пережил нагрузку с дикими тормозами пока первый не загрузица, на втором ситуация повторилась, пришлось тоже перегрузить.
Ну и как итог - сегодня будем готовить третий, иначе говоря как всегда - пока не наебнеца хуй кто зашевелица, несмотря на то что инженер потом позвонил сказал что знал что оно не справляется уже давно.