Every so often I cannot log into the SQL monitor web page and when I look on the server that is hosting the SQL Monitor 2 Web Service, the XSP2.exe process is consuming 99% of the CPU. I restart the service and it goes back down to under 5%. I'm the only one requesting a page, so why would the web service be pegged? I could understand if the base monitor was pegged, but not the web service. Any ideas? Thanks.

There aren't any known issues I can find about this. Is there any pattern to this high CPU usage, and are there other performance issues on the system at the same time? For instance, a long disk queue (>5) or low memory condition can manifest as high CPU. You can get CPU and memory usage from Task manager and disk queue length from perfmon.

If it is actually something in the SQL Monitor code we can try attaching a debugger and dumping the application stacks at the point when things start looking bad. If it happens again, please let us know and we can set this up for you.

I do not recognize any pattern. It has happened a handful of times since we have been using the product, which has been for a few months now. If it happens again, I will get you the metrics you mentioned. Thanks for your help.

The only definite cause I was able to find was this one case where an external requester was DOSing the webserver. Some external IP was making many requests per second for phishing URLs. For example http://server/cgi-bin, http://server/phpbb, etc.

I have a new computer for SQL Monitor this year and just upgraded everything with Redgate to the current version and I'm still having this problem. When I stop the "SQL Monitor 3 Web Service", the cpu frees back up. When I turn the service back on, cpu usage is normal. Is there any way to investigate and keep this from happening?

wrighla wrote:I have a new computer for SQL Monitor this year and just upgraded everything with Redgate to the current version and I'm still having this problem. When I stop the "SQL Monitor 3 Web Service", the cpu frees back up. When I turn the service back on, cpu usage is normal. Is there any way to investigate and keep this from happening?

But then ran the web service .exe directly and could see a socket error... Double checked and some moron had configured IIS with a default website on port 80 (so when xsp2.exe was trying to open the port it was crashing. I changed the port and restarted the service and voila!