shchepanov1 Posted July 12, 2018 · Report post Добрый день! Столкнулись с проблемой падения портов на СКАТ, по логам все 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. Связано ли падения с обновлением ? Может кто сталкивался с данной проблемой? Share this post Link to post Share on other sites
alibek Posted July 12, 2018 · Report post dna объединены в группу? У меня СКАТ падал в тех случаях, когда пропадал один линк из out-группы. Правда bypass отрабатывал. Share this post Link to post Share on other sites
DimaM Posted July 12, 2018 · Report post причины и описание есть в FAQ общая рекомендация : нужно не забывать отключать диагностические режимы = настройки, начинающиеся с trace_ и dbg_ Share this post Link to post Share on other sites
shchepanov1 Posted July 12, 2018 · Report post Спасибо за советы, да действительно проблема была в trace. Share this post Link to post Share on other sites
shchepanov1 Posted July 13, 2018 · Report post К сожалению вовремя не отключили trace, ввиду отсутствия информации в инструкции о загрузке СКАТ диагностическим режимом trace, так же когда support просил включить режим, не сообщил о последствиях долгого включения данного режима. Включали режим ранним утром, но к сожалению клиент не смог проверить в этот день, решили оставить до проверки клиентом, но ночью, а так же утром получили аварию. Получили жалобы от многих клиентов, а также от руководства компании. Share this post Link to post Share on other sites
DimaM Posted July 19, 2018 · Report post Включение trace проявляет себя подобным образом редко, тк похоже, что это специфично только для некоторых серверов. В личку мне подсказали, что поможет изменение стандартного дискового планировщика на deadline: echo deadline > /sys/block/sda/queue/scheduler echo deadline > /sys/block/sdb/queue/scheduler Если будет возможность, то просьба проверить у себя эту рекомендацию, так как на наших серверах эта проблема не проявляется. Share this post Link to post Share on other sites
shchepanov1 Posted July 20, 2018 · Report post Большое спасибо, как появится возможность - проверим. Share this post Link to post Share on other sites
zavndw Posted February 18, 2019 · Report post У вас были еще подобные проблемы? Столкнулись с такой же. Share this post Link to post Share on other sites
shchepanov Posted February 20, 2019 · Report post В 18.02.2019 в 11:38, zavndw сказал: У вас были еще подобные проблемы? Столкнулись с такой же. Нет, больше не сталкивались. (Проблема была из-за включенного traceroute) Share this post Link to post Share on other sites
