We have several dashboards/apps using dbatools to query databases. I’ve noticed on our server that we quickly use a lot of CPU resources. Dashboards that use dbatools, once they’re viewed for the first time, start bouncing between 0 and 24% CPU usage every couple of seconds each averaging about 6% and this continues until the app is restarted, even when no one is viewing the dashboards. Dashboards that aren’t using dbatools drop back to negligible CPU use once rendered.
During testing I’ve found it’s not even necessary to establish a connection to a database; just importing the dbatools module triggers the continual CPU use.
The problem occurs under PowerShell 5.1 and 7.4.1.
I noticed it under dbatools version 1.1.140 but have updated to the latest version (dbatools 2.1.16, dbatools.library 2004.4.12) and removed all old versions and the problem persists.
The dbatools module is installed in the Universal modules repository. I have disabled logging as recommended in another forum post related to dbatools consuming memory.
Just tested it on a container (4.2.19) and 2 standalone Windows hosts running 4.2.20 and 4.2.21, and neither of them are generating any CPU load - tested it in both integrated and seperate PWSH processes.
Can you use perfmon to see, what ressources its using?
Using Process Monitor I found that the processes are trying to access the dbatools log files even though I’ve disabled error and message logging using the SystemDefault scope and confirmed the settings are applied with:
Get-DbatoolsConfig -Fullname logging*
Running the same command in an App shows that logging is still still enabled.
I’ve tried running the commands to disable logging as the service account but that didn’t make a difference; the settings still show as enabled after restarting the App. However, I’ve not yet had chance to stop all the dashboards before disabling logging and I suspect that might be necessary, or possibly even restarting the PSU service.
Something else I’ve not tried is applying the configuration to the SystemMandatory scope which should apply and enforce the configuration for all users. I might resort to that if I can’t disable logging for just the service account.
I added the two environment variables mentioned in the discussion to the machine scope and restarted the PowerShell Universal service. CPU usage has now returned to normal levels and monitoring with Process Monitor confirms the messaging system is disabled (as seen by dashboard processes no longer constantly polling the log files).