• unicorn.god

    defunkt 12 Oct 2009

    Some people have been asking for our Unicorn god 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.

  • Comments

    timocratic Mon Oct 12 11:38:58 -0700 2009

    Unicorn.god? Is that any relation to the Invisible Pink Unicorn, blessed be her hooves?

    jsierles Mon Oct 12 11:45:39 -0700 2009

    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

    dwaite Mon Oct 12 12:02:52 -0700 2009

    So every time a web request stalls, God kills a Unicorn?

    defunkt Mon Oct 12 12:10:54 -0700 2009

    @jsierles Thanks for the tip, looks awesome!

    jsierles Mon Oct 12 13:05:46 -0700 2009

    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?

    leftclick Wed Oct 28 21:00:27 -0700 2009

    Where does that Thread code live? Is that inside unicorn.god?

    Please log in to comment.