Runaway ehttpsrv.exe

[SmackyTheFrog]

I have been getting occasional issues with the ehttpsrv.exe processing going haywire and eating up a full core of cpu cycles out of nowhere. Everything appears to be functioning fine, but console response crawls and client updates a slowed due to CPU contention. Restarting the RA service or even forcing a manual update on the mirror seems to resolve the issue for a few hours, but it eventually comes back. Are other people seeing these same symptoms?

On a side note, while I was picking through the activity on the ehttpsrv process trying to figure out what was going on, I noticed that it is constantly hitting disk to read the update.ver and mod_compat.mod files in the mirror. Why aren't these files kept loaded in memory with the process if they see so much I/O?

[SmackyTheFrog]

Looking at it in process monitor, it seems that the http_dll.dll threads go crazy and start eating cpu cycles when the ehttpsrv process gets a couple orphaned TCP sessions jammed in the CLOSE_WAIT state and it can't recover gracefully from them. I am guessing that when the RA phones back to Eset to look for updated signatures it drops all of its active client sessions including the ones left in the CLOSE_WAIT state which is why the problem clears up at that point.

[DontPanic]

I just checked all 3 of my mirrors and am not seeing any exessive ehttpsrv usage in task manager. You may need to clear cache on mirrror.

[SmackyTheFrog]

I'll clear out the cache and watch it, but I do not think that is the source of my issue considering that while this behavior is happening and those TCP sessions are hung plenty of other systems recieve updates normally. If the cache was corrupt I would expect issues with all clients recieving updates.

[SmackyTheFrog]

Well scratch the idea CLOSE_WAIT theory causing the problem. The problem started again right at the same time I force an update with the cache getting cleared and there were no stuck TCP connections. Forcing an update momentarily kills off the ehttpsrv process and restarts it without the http_dll.dll threads going nuts, at least until the next time it happens.

[reni]

We are experiencing the same issue's now after we installed ERAS on Windows 2008 Server 64bit.

What OS are you guys running?

We have 6000 clients in our ERAS, and the EHttpSrv.exe could handle that easily on windows 2003 (32bit).

Btw i just changed:

<OPTION OPTNAME="ThreadNumber" VALUE="10" />
to
<OPTION OPTNAME="ThreadNumber" VALUE="20" />

in era_http_server.xml

Lets see how it goes with 20 threads, I will post my results later on.

[SmackyTheFrog]

Currently I am serving to about 600 clients on a Server 2003 32-bit vm. Support ended up having me switch over to IIS for the mirror's HTTP host which was a very straightforward process, and I haven't seen the symptoms come back since. I doubt this is an OS-specific issue and more of a problem with the ehttpsrv process not being able to handle high loads in general.

[rcash]

I just loaded RA with a mirror on a windows 2008 server and I am now having the exact same issue. Was this ever resolved other than using IIS?

[SmackyTheFrog]

Nope, I never found a solution aside from shifting things over to IIS. It only took me about 10 minutes to do, though, so you might as well go ahead and give it a shot. http://kb.eset.com/esetkb/index?page=content&id=SOLN2270&actp=search&viewlocale=en_US&searchid=1252533553232