How does maximum-on-demand-scan-threads on MDE Linux affect performance?
Hello. I’m interested in achieving the best performance for on-demand/custom scans. Some of the benchmarks I’ve been seeing are very confusing and I was hoping someone could help clarify.
I have two Linux servers (16 CPU cores each) running MDE. Both servers have an NFS share mounted. There is a folder containing 1859 files that I want to scan.
On the first Linux server, scanning with max 2 threads took just under 16 minutes:
$ sudo mdatp config maximum-on-demand-scan-threads –value 2
Configuration property updated.
$ time mdatp scan custom –path /storage/files
Scan has finished
1859 file(s) scanned
0 threat(s) detected
real 15m57.667s
user 0m0.124s
sys 0m0.111s
Then I bumped the max threads to 16, which reduced the overall time to just over 2 minutes. It sounded great at first, but I reduced back to 2 threads immediately and re-scanned, which took under 2 minutes. To me, this means the drastic time change is not a result of the number of threads, but likely that MDE is caching results.
$ sudo mdatp config maximum-on-demand-scan-threads –value 16
Configuration property updated.
$ time mdatp scan custom –path /storage/files
Scan has finished
1859 file(s) scanned
0 threat(s) detected
real 2m9.889s
user 0m0.030s
sys 0m0.031s
$ sudo mdatp config maximum-on-demand-scan-threads –value 2
Configuration property updated.
$ time mdatp scan custom –path /storage/files
Scan has finished
1859 file(s) scanned
0 threat(s) detected
real 1m54.150s
user 0m0.040s
sys 0m0.030s
Does anyone know if MDE in fact caches results? If so, are they cached locally or on the cloud side? Is there any way to clear the cache? To check if they are cached in the cloud, I ran the same scan from the second Linux server using 16 threads and it took 19 minutes. That suggests the cache is local, if it exists at all.
Some other questions I have:
* maximum-on-demand-scan-threads controls the maximum – is there a way to find out how many are/were used? Aside from the caching issue, scanning with max 2 and max 16 seem to take about the same amount of time.
* Does changing maximum-on-demand-scan-threads take effect immediately? I haven’t seen documentation that suggests it only takes effect after restarting the wdavdaemon services or rebooting, etc.
Side note: The Linux servers do not run auditd. There are no firewall rules blocking network connections (cloud protection is enabled).
Hello. I’m interested in achieving the best performance for on-demand/custom scans. Some of the benchmarks I’ve been seeing are very confusing and I was hoping someone could help clarify. I have two Linux servers (16 CPU cores each) running MDE. Both servers have an NFS share mounted. There is a folder containing 1859 files that I want to scan. On the first Linux server, scanning with max 2 threads took just under 16 minutes: $ sudo mdatp config maximum-on-demand-scan-threads –value 2
Configuration property updated.
$ time mdatp scan custom –path /storage/files
Scan has finished
1859 file(s) scanned
0 threat(s) detected
real 15m57.667s
user 0m0.124s
sys 0m0.111s Then I bumped the max threads to 16, which reduced the overall time to just over 2 minutes. It sounded great at first, but I reduced back to 2 threads immediately and re-scanned, which took under 2 minutes. To me, this means the drastic time change is not a result of the number of threads, but likely that MDE is caching results. $ sudo mdatp config maximum-on-demand-scan-threads –value 16
Configuration property updated.
$ time mdatp scan custom –path /storage/files
Scan has finished
1859 file(s) scanned
0 threat(s) detected
real 2m9.889s
user 0m0.030s
sys 0m0.031s
$ sudo mdatp config maximum-on-demand-scan-threads –value 2
Configuration property updated.
$ time mdatp scan custom –path /storage/files
Scan has finished
1859 file(s) scanned
0 threat(s) detected
real 1m54.150s
user 0m0.040s
sys 0m0.030s Does anyone know if MDE in fact caches results? If so, are they cached locally or on the cloud side? Is there any way to clear the cache? To check if they are cached in the cloud, I ran the same scan from the second Linux server using 16 threads and it took 19 minutes. That suggests the cache is local, if it exists at all. Some other questions I have: * maximum-on-demand-scan-threads controls the maximum – is there a way to find out how many are/were used? Aside from the caching issue, scanning with max 2 and max 16 seem to take about the same amount of time. * Does changing maximum-on-demand-scan-threads take effect immediately? I haven’t seen documentation that suggests it only takes effect after restarting the wdavdaemon services or rebooting, etc. Side note: The Linux servers do not run auditd. There are no firewall rules blocking network connections (cloud protection is enabled). Read More