I have several rails applications running on chai, one large (for me) app with 10 to 15 models, several hundred database rows, etc., and one tiny rails app with 20 to 40 database rows and 4 or 5 models. I converted to passenger to deploy my rails app and it’s WAY better than using dispatch.fcgi, etc.
However, I have tried to deploy the smaller of those two apps on luciano for the actual customer, and the app is killed by dreamhost’s memory hog watcher process. And sure enough, if I do a “ps alx” of my processes, the Rails/Passenger processes on luciano are about twice the size as on chai for the same Rails app: RSS size of 35M vs. 50M and VSZ of 50M vs. 128M.
I cannot figure out what numbers dreamhost uses to make its decision on whether to kill a process (RSS or VSZ). VSZ can be very misleading, and could, for example be way larger depending on how large the per-thread stack size is on a particular machine. However, since the RSS sizes are also larger I think there must be something else going on.
Has anybody else had this problem? The side-effect of having my ruby process killed from time to time is that the next refresh of the web page produces a large, ugly Passenger stack trace trying to spawn a new process. And the reason for that is that the OLD one is still around in a Zombie state. The memory reaper process kills the Rails app in a way that the Passenger spawner does not like. The Zombie disappears right after the stack trace so the very next HTTP request works, but obviously one cannot have a stack trace on one’s production website.