I have ruby 1.8.6, rails 2.1.0 in an Apache 2.0.59 / mod_fastcgi 2.4.6
setting on RedHat Enterprise.
After a server restart the first 2, 3, 4 requests are served nicely
and then latency time jumps to 20 seconds, 40 seconds or even timeout.
On the server I see multiple dispatch.fcgi processes (which is ok, my
configuration requests up to 8 of these guys) running and jointly
pushing CPU to 100% load, even when there are no requests any more and
the CPU should be idling. The processes also ignore the FastCGI
timeout value given in httpd.conf.
I did instrument class RailsFCGIHandler to see where the guys go
looping, but no result.
So I am staring at a responseless server with looping dispatchers -
having a nice application sitting on my disc ready to be deployed on
production server - and a less and less nice boss inquirying about the
status and the deadline.
I did instrument class RailsFCGIHandler to see where the guys go
looping, but no result.
So I am staring at a responseless server with looping dispatchers -
having a nice application sitting on my disc ready to be deployed on
production server - and a less and less nice boss inquirying about the
status and the deadline.
Any ideas ?
Don't use fastcgi? It's hardly the most popular/common option these
days.
A pack of mongrels is usually as fast or faster. Most people have
moved to nginx/apache+mod_proxy_balancer in front of a cluster of
mongrels. In the past few months mod_rails has been getting a lot of
of interest too. Back when I moved away from fastcgi (2 years ago or
so), it was mostly motivated by reliabilty problems with fastcgi than
speed itself.
Ok. I realized that FASTcgi might not be the proper solution so I
deinstalled fastcgi completely to get a clean Apache and installed
mod_rails / Passenger.
So, now I am getting the first two or three pages really fast...and
then I have "ruby" processes sitting there and eating up 100% of CPU
performance.
