Добрый день
Наблюдаю по запросу 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 около нечитаем, спам безбожнейший
Попробуйте, пожалуйста, на 5.2.7, там был один фикс на тему дискавери (https://track.radensolutions.com/issue/NX-2594)
Обновился на 5.2.7
Процесс похоже с начала пошел, пока наблюдаю
Quote from: Filipp Sudanov on November 10, 2025, 12:53:59 PMПопробуйте, пожалуйста, на 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
Сервер на Windows или Линуксе?
Развернуто на ВМ с 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
Вот скрипт который собирает информацию о тредах netxmsd: https://github.com/netxms/netxms/blob/master/tools/capture_netxmsd_threads.sh
В системе должны стоять пакеты netxms-dbg и gdb.
Скрипт нужно запустить 3 раза и интервалом в 20-30 секунд. Он сделает файлики в /tmp, пришлите их, можно в личном сообщении.
Отправил логи в пм
Да, спасибо, ждут пока разработчик посмотрит
А какое значение DBWriter.BackgroundWorkers на этой системе?
DBWriter.BackgroundWorkers 10
Как и
DBWriter.DataQueues 10
DBWriter.InsertParallelismDegree 10
DBWriter.UpdateParallelismDegree 10
По ключу DBWriter это все, что менял
В дебаг информации не видно, чтоб дискавери прямо завис, он там что-то продолжает делать, во всех тредах он на разном месте в коде.
Есть шанс что настройки DBWriter чересчур накручены и ему мешают. DBWriter.DataQueues в случае таймскейла нет смысла поднимать больше 1, т.к. по сути там все данные DCI пишутся в одну таблицу - idata_sc_default. DBWriter.BackgroundWorkers тоже следует поднимать осторожно, т.к. когда их много, то они начинают мешать друг другу, по нашему опыту больше 4 их не нужно.
Спасибо, изменил параметры, понаблюдаю.
Таймер активного скана выставлен на 7200
А как оно работает при скане вообще? Радиус 10.6.1.1-10.6.254.254 точно содержит в себе ноды, но большая часть адресов здесь не активны. Проблема как раз в том, что у меня нет информации что активно, а что нет для сужения круга. Может быть проблема в том, что сильно растягивается скан из-за ожидания ответа от ICMP неактивных адресов?
На первом этапе дискавери сервер высылает пачку ICMP запросов на много адресов сразу (NetworkDiscovery.ActiveDiscovery.BlockSize - по умолчанию 1024), ждет ответов и рассылает следующую пачку. Так что список ответивших адресов он собирает достаточно быстро.
Дальше там два этапа - первоначальный сбор данных о каждом адресе - это делают паралельные треды (в количестве ThreadPool.Discovery.MaxSize) и потом есть один тред, который анализирует эти данные и решает что делать (один, потому что у одного девайса может быть несколько адресов, а мы не хотим насоздавать несколько нод).
В Debug Console по команде show queues показывается Node discovery poller, но это сумма очередей каждого из этих этапов. В 6.0 размер этих очередей скорее всего будет виден по-отдельности, когда-нибудь в будущем этот тикет может будет сделан: https://track.radensolutions.com/issue/NX-2616