Some people have been asking for our Unicorngod config.
Here it is:
That’s for starting and stopping the master. It’s important to note that god only knows about the master – not the workers. The memory limit condition, then, only applies to the master (and is probably never hit).
To watch the workers we use a cute hack mojombo came up with (though he promises first class support in future versions of code): we start a thread and periodically check the memory usage of workers. If a worker is gobbling up more than 300mb of RSS, we send it a QUIT. The QUIT tells it to die once it finishes processing the current request. Once that happens the master will spawn a new worker – we should hardly notice.
That’s it! Don’t forget the Unicorn Signals page when working with Unicorn.
Where is the thread created? Inside the god config or run in a separate process?
Also, we're looking for a way to make individual processes restartable as the user specified in the watch. Changing the socket permissions is the current solution. Any other ways?
Unicorn.god? Is that any relation to the Invisible Pink Unicorn, blessed be her hooves?
This is great! We're using this config in staging and it looks good so far.
One suggestion for the watchdog script is to check the actual memory usage (ps output lies) as Passenger does, using this handy trick on Linux:
http://gist.github.com/208619
So every time a web request stalls, God kills a Unicorn?
@jsierles Thanks for the tip, looks awesome!
Where is the thread created? Inside the god config or run in a separate process?
Also, we're looking for a way to make individual processes restartable as the user specified in the watch. Changing the socket permissions is the current solution. Any other ways?
Where does that Thread code live? Is that inside unicorn.god?