Server Maintenance Tasks

This page covers common server maintenance procedures, including modifying configuration variables, adjusting the housekeeping schedule, tuning thread pools, enabling debug logging, and configuring inter-server communication.

For a complete list of server configuration parameters and variables, see Server Configuration.

Modifying Configuration Variables via CLI

Use nxdbmgr to modify server configuration variables from the command line without using the management client:

nxdbmgr set <variable_name> <value>
Example: Change the default DCI polling interval to 120 seconds
nxdbmgr set DataCollection.DefaultDCIPollingInterval 120

nxdbmgr set writes directly to the database. A running server does not re-read configuration variables from the database, so changes made this way take effect only after the server is restarted. To change a variable on a running server, use the management client (Configuration > Server Configuration) or the set <variable> <value> command in the server debug console — both apply the change immediately, unless the variable itself is marked as requiring a restart.

nxdbmgr set creates the variable if it does not exist — a misspelled variable name silently creates a new, unused variable instead of failing.

Adjusting the Housekeeping Schedule

NetXMS server performs automatic housekeeping to clean up expired data from the database. The housekeeping process runs at a configurable time and throttle rate. Adjust these variables if the default schedule conflicts with peak usage or if housekeeping takes too long:

  • Housekeeper.StartTime — time to run housekeeping (default: 02:00); changing this variable requires a server restart

  • Housekeeper.Throttle.HighWatermark — combined length of the database writer queues (general and collected-data writers) at which the housekeeper pauses (default: 250000)

  • Housekeeper.Throttle.LowWatermark — queue length at which a paused housekeeper resumes (default: 50000)

See Housekeeping Variables for the full list. To run housekeeping immediately, use the hkrun command in the server debug console.

If additional periodic cleanup is needed (for example, purging custom database tables), place NXSL scripts in the housekeeper subdirectory of the server data directory — every *.nxsl file there is executed as part of each housekeeper cycle. A scheduled Execute.Script task (see Scheduling) is an alternative when the cleanup should run on its own schedule.

Thread Pool Tuning

For large installations, tuning thread pool sizes can improve server performance. NetXMS uses several thread pools that can be adjusted based on your monitoring load.

Default pool sizes are adequate for most installations. Bigger is not better: oversized pools waste memory and can degrade performance. Adjust them only when there is evidence of a problem — a pool’s load staying at its maximum size or requests waiting in its queue, as reported by the Server.ThreadPool.* internal metrics.

The key thread pools and their purposes (configuration variable prefix, with the runtime pool name used in metrics in parentheses):

  • DataCollector (DATACOLL) — handles DCI polling; increase if you have many DCIs and see collection delays

  • Main (MAIN) — general server operations; increase for large deployments

  • Poller (POLLERS) — status and configuration polls; increase if polls are queuing up

  • Scheduler (SCHEDULER) — scheduled task execution

To tune a thread pool:

  1. Check current utilization using the Server.ThreadPool.* internal metrics on the management server node — for example, Server.ThreadPool.Load(POLLERS) or Server.ThreadPool.Load(DATACOLL). The metrics take the runtime pool name, not the configuration variable prefix.

    For a quick look without creating DCIs, run show threads in the server debug console (available in the management client under Tools > Server debug console or locally via nxadm -i). It prints, for every pool (or for one pool with show threads <pool>), the thread count (current, minimum, and maximum), load average, usage, active and scheduled requests, and queue size and wait time statistics. A pool is saturated when Usage stays at 100% (thread count at its maximum) and Queue size EMA keeps growing.

  2. If a pool is saturated, increase the maximum thread count and restart the server (all ThreadPool.* variables take effect only at startup):

    nxdbmgr set ThreadPool.DataCollector.MaxSize 500

  3. Monitor the impact after changes — setting pools too large wastes memory

Start by increasing only the saturated pool. Doubling the maximum is usually sufficient.

See Thread Pool Variables for all configurable parameters.

Enabling Debug Logging

To enable debug logging for troubleshooting, you can either modify the configuration file or change the level at runtime. The debug console used below is available locally via nxadm -i or in the management client under Tools > Server debug console (see Debug Console).

Via Configuration File

Set the debug level in netxmsd.conf and restart the server:

DebugLevel = 7

Levels for specific tags can be set with the DebugTags parameter, a comma-separated list of tag:level entries:

DebugTags = poll.status:7,db.query:5

Via Debug Console (No Restart)

Change the debug level at runtime using the debug console:

debug 7

Or set debug level per-tag for targeted diagnostics:

debug poll.status 7
debug db.query 5

To reset a tag to the default level, set its level to -1:

debug poll.status -1

See Common Debug Tags for the tags used most often; debug without arguments lists all tags with a level currently set.

Debug level 7 or above generates significant log output and can affect performance. Use only for troubleshooting and remember to restore the default level (0) afterward.

Setting Up Inter-Server Communication (ISC)

NetXMS provides an Inter-Server Communication (ISC) protocol for server-to-server interaction. The primary use case is event forwarding — sending events from one NetXMS server to another in distributed monitoring setups.

Enabling ISC on the Receiving Server

  1. Set EnableISCListener to true and restart the server

  2. Set Events.ReceiveForwardedEvents to true

  3. Open TCP port 4702 in the firewall

Configuring the Sending Server

On the sending server, create an event forwarder (Configuration > Event Forwarders, isc driver with the destination hostname), create a "Forward event" action referencing that forwarder, and use it in EPP rules to select which events to forward.

ISC uses the NXCP protocol. The built-in isc event forwarding driver connects with encryption disabled, so forwarded events are sent unencrypted; use a secure network path (VPN, private link) between the servers. The connection is initiated by the sending server for each forwarded event.

For detailed configuration steps and limitations, see Event Forwarding. See ISC Variables for configuration parameters.