httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jon Snow <>
Subject Re: High CPU utilization on using Apache as a reverse proxy
Date Thu, 17 Aug 2006 16:48:18 GMT


I can't remember if I posted the results of the SSL issue and high CPU usage. 
We tracked it to a bug in the solaris driver for the Sun daughter card, some 
mutex issue if my memory serves me correctly. Sun confirmed and issued a 
patch a while ago. As discussed in the quoted post I did not believe it was 
an apache issue for the SSL but I showed dumps for a corresponding write 
issue with a forward proxy in an early anticipation it may be related.

This forward proxy problem I had sounds similar to your issue where apache 
appears not to test a return value for a write but it did not utilise large 
CPU. Currently I run 2.2.2 and have observed the same write problem as I did 
with 2.0.53. One main issue I have with this is the download continues while 
the write fails so effectively the active connection is not in sound 
communication with the passive. 

I put the huge memory usage down to the byte range bug as these processes were 
nearly always streaming or FTPing large files. I have not seen this memory 
usage with the version I am running even when I see the write problem.

To clarify your issue are you running SSL and if so are you using hardware 
crypto? I assume you are using solaris, is it patched for crypto re: above 
and what version of solaris are you using?

On Tuesday 15 August 2006 00:47, pradeep kumar wrote:
> Hi,
> I notice there is a 100% CPU utilization which spikes for sometime and then
> goes back to normalcy when Apache is used a reverse proxy. I noticed a mail
> thread which seems to be a similar problem
> One thread of one of the child processes hangs, calling poll() and writev()
> system calls so frequently that it causes 100% CPU util. The thread is
> trying to writev() to a socked which is in CLOSE_WAIT The child process
> ends after time defined by ndd parameter tcp_keepalive_interval and the
> same service time can be seen in access_log. The problem disappears then.
> Regards,
> Pradeep

View raw message