1

If I'm correct when I think that a line of

30193 ramon     16   0  170M  119M  3628 S  0.0 11.6  0:08.47 Rack: /var/www/salcedoauctions/current

in htop means that there's one spawn of the salcedoauctions app, then how come there are so many more spawns than I've specified?

Here's my httpd.conf:

....
PassengerMaxPoolSize 4
PassengerMaxInstancesPerApp 2
....

Here's the semi-complete htop:

  PID USER     PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command
30193 ramon     16   0  170M  119M  3628 S  0.0 11.6  0:08.47 Rack: /var/www/salcedoauctions/current
30197 ramon     18   0  170M  119M  3628 S  0.0 11.6  0:02.08 Rack: /var/www/salcedoauctions/current
30198 ramon     18   0  170M  119M  3628 S  0.0 11.6  0:01.96 Rack: /var/www/salcedoauctions/current
30199 ramon     18   0  170M  119M  3628 S  0.0 11.6  0:01.96 Rack: /var/www/salcedoauctions/current
30067 ramon     15   0  167M  117M  3648 S  0.0 11.5  0:08.77 Rack: /var/www/salcedoauctions/current
30202 ramon     16   0  167M  117M  3648 S  0.0 11.5  0:04.55 Rack: /var/www/salcedoauctions/current
30203 ramon     16   0  167M  117M  3648 S  0.0 11.5  0:03.43 Rack: /var/www/salcedoauctions/current
30204 ramon     16   0  167M  117M  3648 S  0.0 11.5  0:03.32 Rack: /var/www/salcedoauctions/current
28454 ramon     16   0 73764 51732  2520 S  0.0  4.9  0:00.66 Rack: /var/www/unstilted/current
.....

Some notes:

  • Yes, I've restarted apache so it can reload the config (several times, in fact, since the server was running out of memory)
  • CentOS 5.5
  • Ruby EE 1.8.7
  • Rails 3.0.1
  • Passenger 3.0.0

  • UPDATE #1 Doing passenger-status shows the numbers I expect to see though though. I suppose I just understood it wrong. The reason I'm asking is because my 1GB memory is getting used up and sometimes the server grinds to a halt. It seems that those processes are hogging the RAM.

  • UPDATE #2: I asked around in #rubyonrails and I was asked if any of the apps were forking any processes. Both apps don't fork anything, but I do use Dragonfly to handle my images and attachments. However, I don't know how I can pinpoint if this is the cause of the problem.
  • UPDATE #3 (Oct 14, 2011): I upgraded to Ruby 1.9.2, Rails 3.1.x, dragonfly 0.9.3, ImageMagick 6.7; and I'm still getting the same problem. It's not Dragonfly anymore because the newer versions don't use rmagick. It does a command line call to convert images.
2
  • I got an answer from Mark Evans, the guy that made dragonfly. Dragonfly does not deal with spawning, but did require RMagick, which may explain running out of memory. Maybe it's RMagick that's spawning the processes then? Feb 27, 2011 at 17:42
  • Just so you know, this wasn't the cause of the problem. I post up an update in the answer. Oct 17, 2011 at 8:56

1 Answer 1

0

For tracking down these problems, running passenger-status -v on the server will give a good overview of what is actually active. Likewise, passenger-memory-status will give you a nice overview of mem usage.

Regarding versions, consider upgrading to passenger > 3.0.7 - I had similar problems with rails/dragonfly and memory leaks under early 3.0 releases. ImageMagick 6.6.0 and rmagick 2.13.1 have been working well for a while in production.

1
  • I upgraded to Ruby 1.9.2, Rails 3.1.x, dragonfly 0.9.3, ImageMagick 6.7; and I'm still getting the same problem. It's not Dragonfly anymore because the newer versions don't use rmagick. It does a command line call to convert images. Oct 14, 2011 at 16:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .