Have you ever increased the threads on MID server for Discovery?

[Suggy]

Have you ever increased the threads on MID server in Discovery projects for discovering the CI's?

If yes, what made you to increase the threads?

and what values did you set for 'wrapper.java.maxmemory' and threads.max? (anything else you increased?)

Thanks in advance!

[srinija_itom]

Hi @Suggy ,

We have increased the threads of the MID's from default value to 25 to 50 threads. 

We have set 'wrapper.java.maxmemory' (Max heap size) to 2GB (2048 mb) from 1 GB (1024mb)

Discovery Schedules will take longer to complete when the MID Server has less threads available to perform tasks concurrently.

Please check the below link from ServiceNow Community. 

https://noderegister.service-now.com/kb?id=kb_article_view&sysparm_article=KB0997594

If the above info is helpful, please accept the solution or mark the solution as helpful.

Regards, 

Srinija

[Suggy]

@srinija_itom Thanks a lot for sharing the details.

May I also know how much time was saved when you increased the parameters of MID.

By the way I was quite surprised why KB0997594 doesnt mention anything about increasing JVM as its closely related to thread count.

[srinija_itom]

Hi @Suggy, 

It varies from environment to environment. I can’t share how much time it saved for us. Increasing the thread count definitely improves the performance of the discovery schedules. 

if you would like to test, increase thread count on any of the dev mid server and run a discovery schedule and compare the time with the existing discovery schedule in the production. Make sure same number of mid’s are assigned to the each schedule in both environments. 

Regards, 

srinija

[AJ-TechTrek]

Hi @Suggy ,

Have I increased threads on the MID Server?

Yes — in larger discovery projects (e.g., discovering thousands of servers, network devices, storage, or large cloud estates), we do increase the thread count beyond the default to improve parallelism and speed.

Why increase threads?
* Default thread pool size (glide.discovery.max_probe_threads) is 10.
* When you have:
* Many CIs in the same schedule,
* Large subnets,
* Tight discovery windows,
* Increasing threads helps reduce total discovery duration.
BUT:
* Increasing threads increases CPU and memory load on the MID server.
* Needs careful tuning + monitoring.

System resources sizing (host VM):
For high concurrency, we typically recommend:
Resource     Minimum     Typical for larger discovery
vCPU  -          2–4                   8–16 vCPU
RAM-           4 GB                   16–32 GB RAM
Disk-            20 GB+              40 GB+ (depends on logs & ECC Queue backlog)

Note: For very large discovery, MID should be on a dedicated VM — don’t co-host other services.

Typical values we set:

Increase discovery threads

Parameter                                                         Default                              Example higher value
glide.discovery.max_probe_threads -        10                                30–50 (depends on resources and network capacity)

Start incrementally: e.g., 10 → 20 → 30, monitor MID CPU, ECC queue backlog, and network utilization.

wrapper.java.maxmemory (Max heap size):

Default                                                   Recommended for large discovery
~256–512 MB                                              2 GB (2048 MB) to 4 GB (4096 MB)

E.g., in wrapper.conf:
wrapper.java.maxmemory=4096

Ensure the MID Server host has enough physical RAM to support this.
Monitor JVM memory usage via the MID Server dashboard.

Important considerations:
* Increasing threads won’t always linearly speed up discovery (depends on target device response time & network latency).
Must ensure:
* MID server can handle load (CPU, RAM).
* Network isn’t overloaded.
* ECC Queue on instance doesn’t back up.
* Regularly monitor:
* ECC Queue health
* MID JVM heap usage
* MID CPU/RAM utilization

Best practice summary:
1.Increase threads gradually, while:
* Up-sizing MID server resources (CPU & RAM).
* Increasing wrapper.java.maxmemory (typically to 2–4 GB).
* Testing during low business hours first.
2.Document the rationale & baseline performance vs. after tuning.

Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.
 
Thank You
AJ - TechTrek with AJ
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
ServiceNow Community MVP 2025

[Suggy]

Hi @AJ-TechTrek 

Thanks for sharing your inputs. I have few questions:

1. No where I could find details about this - glide.discovery.max_probe_threads

Can you share more details on that

2. You mentioned 

"Start incrementally: e.g., 10 → 20 → 30, monitor MID CPU, ECC queue backlog, and network utilization."

but ServiceNow ships with default of 25 threads. How 10,20 comes here

Is that a generic content that you shared?