Excessive instances of oecgi4

AusMarkB

We have a client whose web app was recently reported as "down" but upon investigation, the cpu and ram on the webserver were really just maxing out so many requests were simply timing out.
A restart of the socketserver (I'm running in debug mode rather than as a service) made everyone happy again.
Before doing so, a scroll down through task manager processes indicated an excessive number of oecgi4 instances. I started to count but I think I gave up somewhere in the vicinity of 200 with plenty more to go.

We have the enginecount limited to ten and they were all working fine but I'm curious if this is expected or potentially expected behaviour? Does each instance of oecgi4 represent a waiting/processing request and the service is just getting genuinely slammed or is this indicative of something gone awry?

DonBakke

I think this is indicative of something gone awry. What version of Windows is this? Do all of those OECGI instances have WMI Performance Adapter as a sub-task?

AusMarkB

I don't think all of them did but several for sure. That screenshot is just over a week old and if I check now, whilst fluctuating, there doesn't seem to be more than six at any one time.

AusMarkB

We had the same app/site being reported as down today. I restarted the socketserver and nothing happened. No engines were fired which suggested no requests were coming in.
A restart of IIS set everything back to normal but with all ten engines working together to max out the cpu.
A scroll through task manager and I see the extreme number of instances of oecgi4 again. Stop the socketserver and the instances of oecgi4 drop to about half a dozen. Restart the socketserver and they shoot straight back up.

Any hints as to what each instance of oecgi would actually represent?

Here's a couple of videos demonstrating what I'm rambling.
Engines maxing cpu
Look at all our oecgis