I've been having some issues over the past few days with our WSUS server eating 100% CPU usage. We don't have many clients (maybe 30 or so at most), so that's not the issue (Not to mention that this server had more in the past).
So, in my debugging, I've completely re-installed both WSUS and Windows Internal Database (SQL Server 2005) several times (Nuking the db and download files each time), and keep having the same issue.
sqlservr.exe uses around 85% of the available CPU, and
wsusservice.exe uses the other 15%. Keep in mind that basically nothing is happening on the server at this point (no clients connected, etc).
I opened up task manager, and I see that between the two processes, they are using around 275 mb of ram (on a 1024 mb system). However, the page faults just keep racking up (sitting at around 7k to 10k per second). So, in an attempt to see if that was the problem, I disabled the page file in windows and restarted. I'm still seeing the high rate of page faults. And the performance tab of task manager still shows about 600mb worth of PF usage... What I don't understand, is why is it still tracking PF usage if there is no paging file...? (The drives are thrashing, so something is going on with the disk, and I can't see very much disk I/O in task manager. And the VMWare manager is showing a moderate write rate since I disabled the PF, about 1.5 Mbps. It's also showing a falloff in the read rate, 9 Kbps. The drives are capable of burst rates much higher than that, so I can only assume it's due to seeks why it's so low (random writes)).
The Commit Charge is as follows:
- Total: 634408
- Limit: 960004
- Peak: 657512
The Physical Memory is as follows:
- Total: 1048012
- Available: 21864
- Cache: 402168
Oh, and it's running Server 2k3 SP1 on a VMware ESXi 3.5 server (Quad Xeon, 8gb ram and 6 x u320 SCSI HDD).
I'm lost at this point as to how to continue with this...
Actually, in the time I've written this, the
sqlservr.exe process's memory usage has jumped from around 100mb to 330mb. It's doing a synchronization now, so I can understand the increase, but still it never used to eat up 100% CPU for something simple like a full sync...