Перейти к содержимому
Калькуляторы

СКАТ DPI падения портов

Добрый день! Столкнулись с проблемой падения портов на СКАТ, по логам все dna падают одновременно. При этом в логах ошибка:  bpm : thread #1 - does not change self-monitoring counters, check_pnt=1(1),cntr_before=853023215046(853023215046$ [ERROR ][2018/07/12-03:42:07:667687][0x7f478bb85700] bpm : thread #1 - does not change self-monitoring counters, check_pnt=1(1),cntr_before=853023215046(853023215046$ [CRITICAL][2018/07/12-03:42:17:750655][0x7f478bb85700] bpm : self-monitoring counters unchanged 2 consecutive interval. Call abort.

Скат стоит в разрыв с операторами. На DPI стоит сетевая карта с bypass, при падении портов перехода на bypass не было.

11.07 обновили fastdpi с 7.1 до последней актуальной версии. Падения портов были 12.07 в 3:42 и 9:53.

Связано ли падения с обновлением ?

Может кто сталкивался с данной проблемой?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

dna объединены в группу?

У меня СКАТ падал в тех случаях, когда пропадал один линк из out-группы.

Правда bypass отрабатывал.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

причины и описание есть в FAQ

общая рекомендация : нужно не забывать отключать диагностические режимы = настройки, начинающиеся с trace_ и dbg_  

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Спасибо за советы, да действительно проблема была в trace.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

К сожалению вовремя не отключили trace, ввиду отсутствия информации в инструкции о загрузке СКАТ диагностическим режимом trace, так же когда support просил включить режим, не сообщил о последствиях долгого включения данного режима. Включали режим ранним утром, но к сожалению клиент не смог проверить в этот день, решили оставить до проверки клиентом, но ночью, а так же утром  получили аварию. Получили жалобы от многих клиентов, а также от руководства компании.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Включение trace проявляет себя подобным образом редко, тк похоже, что это специфично только для некоторых серверов.

В личку мне подсказали, что поможет изменение стандартного дискового планировщика на deadline:

echo deadline > /sys/block/sda/queue/scheduler
echo deadline > /sys/block/sdb/queue/scheduler

Если будет возможность, то просьба проверить у себя эту рекомендацию, так как на наших серверах эта проблема не проявляется.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Большое спасибо, как появится возможность - проверим.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У вас были еще подобные проблемы? Столкнулись с такой же.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 18.02.2019 в 11:38, zavndw сказал:

У вас были еще подобные проблемы? Столкнулись с такой же.

Нет, больше не сталкивались. (Проблема была из-за включенного traceroute)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.