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