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