Active discovery застрял

[Argonauts]

Добрый день

Наблюдаю по запросу sh disc ranges вот такую картину

Active discovery poller is RUNNING
Address ranges:
   192.168.16.1-192.168.16.254          completed
   10.3.1.1-10.3.254.254                completed
   10.6.1.1-10.6.254.254                processing
   10.8.1.1-10.8.254.254                pending
   192.168.1.1-192.168.36.254           pending

Не меняется его состояние этак с момента установки ренджей, т.е. пару месяцев точно. При этом разные ноды добавляются. Как мне понять на чем он споткнулся и можно ли перезапустить вручную этот процесс? Debug 6 на poll.discovery около нечитаем, спам безбожнейший

[Filipp Sudanov]

Попробуйте, пожалуйста, на 5.2.7, там был один фикс на тему дискавери (https://track.radensolutions.com/issue/NX-2594)

[Argonauts]

Обновился на 5.2.7
Процесс похоже с начала пошел, пока наблюдаю

[Argonauts]

@filipp-sudanov said in Active discovery застрял:

Попробуйте, пожалуйста, на 5.2.7, там был один фикс на тему дискавери (https://track.radensolutions.com/issue/NX-2594)

В какой-то момент так же остановился процесс

Active discovery poller is RUNNING
Address ranges:
   192.168.16.1-192.168.16.254          completed
   10.3.1.1-10.3.254.254                completed
   10.6.1.1-10.6.254.254                processing
   10.8.1.1-10.8.254.254                pending
   192.168.1.1-192.168.36.254           pending

[Filipp Sudanov]

Сервер на Windows или Линуксе?

[Argonauts]

Развернуто на ВМ с Ubuntu Server 24.04.3. На одной машине база, сервер, веб-морда
16 потоков
20Gb выделенной ОЗУ
4Gb свап, но особо не видел, чтобы в него много сливалось
База postgreSQL с timescale, но такой затык со сканом был и на старой базе до конверта в timescale.

NetXMS Server Version 5.2.7 Build 5.2-484-g5df9cb5911
NXCP: 5.62.1.53 (AES-256, 3DES, AES-128)
Built with: g++ (Ubuntu 13.2.0-23ubuntu4) 13.2.0

[Filipp Sudanov]

Вот скрипт который собирает информацию о тредах netxmsd: https://github.com/netxms/netxms/blob/master/tools/capture_netxmsd_threads.sh

В системе должны стоять пакеты netxms-dbg и gdb.

Скрипт нужно запустить 3 раза и интервалом в 20-30 секунд. Он сделает файлики в /tmp, пришлите их, можно в личном сообщении.

[Argonauts]

Отправил логи в пм

[Filipp Sudanov]

Да, спасибо, ждут пока разработчик посмотрит

[Filipp Sudanov]

А какое значение DBWriter.BackgroundWorkers на этой системе?

[Argonauts]

DBWriter.BackgroundWorkers 10

Как и
DBWriter.DataQueues 10
DBWriter.InsertParallelismDegree 10
DBWriter.UpdateParallelismDegree 10

По ключу DBWriter это все, что менял

[Filipp Sudanov]

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

Есть шанс что настройки DBWriter чересчур накручены и ему мешают. DBWriter.DataQueues в случае таймскейла нет смысла поднимать больше 1, т.к. по сути там все данные DCI пишутся в одну таблицу - idata_sc_default. DBWriter.BackgroundWorkers тоже следует поднимать осторожно, т.к. когда их много, то они начинают мешать друг другу, по нашему опыту больше 4 их не нужно.

[Argonauts]

Спасибо, изменил параметры, понаблюдаю.
Таймер активного скана выставлен на 7200
А как оно работает при скане вообще? Радиус 10.6.1.1-10.6.254.254 точно содержит в себе ноды, но большая часть адресов здесь не активны. Проблема как раз в том, что у меня нет информации что активно, а что нет для сужения круга. Может быть проблема в том, что сильно растягивается скан из-за ожидания ответа от ICMP неактивных адресов?

[Filipp Sudanov]

На первом этапе дискавери сервер высылает пачку ICMP запросов на много адресов сразу (NetworkDiscovery.ActiveDiscovery.BlockSize - по умолчанию 1024), ждет ответов и рассылает следующую пачку. Так что список ответивших адресов он собирает достаточно быстро.
Дальше там два этапа - первоначальный сбор данных о каждом адресе - это делают паралельные треды (в количестве ThreadPool.Discovery.MaxSize) и потом есть один тред, который анализирует эти данные и решает что делать (один, потому что у одного девайса может быть несколько адресов, а мы не хотим насоздавать несколько нод).
В Debug Console по команде show queues показывается Node discovery poller, но это сумма очередей каждого из этих этапов. В 6.0 размер этих очередей скорее всего будет виден по-отдельности, когда-нибудь в будущем этот тикет может будет сделан: https://track.radensolutions.com/issue/NX-2616