Family, work and life in general.
In: Ruby| Systems Architecture
25 Aug 2009When I recently resurrected this blog from after an untimely demise, I found it interesting to see how many people still get here from Google by querying for God. When I first wrote that article, I had been planning to launch a little app for home brewers that I was writing in my spare time. I still have the project around and I do plan to launch it at some point, but its not on my short list of things to-do with my ever dwindling spare time (I have twin babies due in seven weeks).
Since then, I’ve started a new job with Agora Games as CTO, and our (good natured, ninja, rockstar) systems administrator Jason LaPorte sold me on Monit. Why would a guy who gets most of his blog traffic (read: all 10 of you) based on a Google referral for GOD use Monit? I think there’s a few reasons.
God is good. God is great. But, when you architect web applications for a living, eventually you realize that however great Ruby is (and Ruby as a language is truly awesome), having one less MRI process running, eating up RAM on your servers is really nice. Its even nicer when your using a virtual hosting solution and you’re paying a premium for memory. At this point, until we have a better Ruby interpreter my money (and our business) runs on Monit. YMMV.
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Quisque sed felis. Aliquam sit amet felis. Mauris semper, velit semper laoreet dictum, quam diam dictum urna, nec placerat elit nisl in quam. Etiam augue pede, molestie eget, rhoncus at, convallis ut, eros. Aliquam pharetra.
1 Response to On GOD and MONIT
Jason LaPorte
August 25th, 2009 at 12:25 pm
General rule of thumb: “BE WARY OF LONG-RUNNING RUBY PROCESSES.” Despite the popularity of Rails and the general awesomeness of Ruby, Ruby is *not* particularly stable, especially in terms of memory usage and in terms of IO.
This is why you shouldn’t monitor Ruby with Ruby, and why we use Monit. (Also, Monit doesn’t suck, so that helps too.)