Using bluepill to save memory.

41 views
Skip to first unread message

tim

unread,
Apr 17, 2011, 5:52:08 PM4/17/11
to Bluepill
Hey All.

I am using bluepill with daemon spawn to manage a hundred or so
daemons on several servers. The current setup goes like this.

All the daemons are written using daemon spawn. They can be started
and stopped using command line arguments to run standalone. I don't
use the command line to stop them because they sometimes they "get
stuck" so I have a script that sends a TERM signal, waits 30 seconds
and then sends a SIGKILL if it's still alive.

Every daemon loads the rails environment. Some fork other shorter
running processes.


I manage all of them with bluepill using a custom configuration file
that launches the proper number of workers on each server.

My problem is that each daemon takes up tons of RAM so I am exploring
ways to save RAM by building a forking supervisor (using REE so copy
on write should theoretically save me lots of RAM) but since I am
using bluepill anyway I was wondering if bluepill would work for me.

My idea is to rewrite the daemons so they don't use daemon spawn and
have bluepill fork them. I would include the rails environment in the
bluepill.rb so it could be "shared" amongst the forks along with all
the rest of the gems and whatnot.

Would this work?

Cheers.

tim

unread,
Apr 24, 2011, 5:40:21 AM4/24/11
to Bluepill
Hey guys I hate to bump my own question but I am wondering if anybody
has any input on whether I can use bluepill to save memory when
launching multiple daemons.

I was looking at the source code for resque-pool and the author talks
about how it's possible to save memory using the copy on write
features of REE. From what I can tell bluepill might be able to
accomplish the same thing and I am wondering if anybody more familiar
with the code has any thoughts on this.

Thanks.

Curtis j Schofield

unread,
Apr 25, 2011, 7:14:45 PM4/25/11
to bluep...@googlegroups.com


Hi Tim.

Sounds like your idea has validity. It may be worth an experiment - but actually
i think what you would really like to do is build on top of unicorn horn.

https://github.com/jxe/unicorn_horn


I'm a bit curious why you have hundreds of daemons.


--
make haste slowly \
festina lente  \
-
mobile  +1_415_632_6001
curtis.s...@gmail.com
http://robotarmyma.de

Tim Uckun

unread,
Apr 25, 2011, 9:46:35 PM4/25/11
to bluep...@googlegroups.com
>
> Sounds like your idea has validity. It may be worth an experiment - but actually
> i think what you would really like to do is build on top of unicorn horn.
>
> https://github.com/jxe/unicorn_horn

That looks interesting. Perhaps I will dig into that sometime.

> I'm a bit curious why you have hundreds of daemons.

I don't have hundreds. I have about 80 but soon may hit a hundred.
They are running on different machines about twenty per machine. How
many I can run is limited by the RAM in the VPS so if I can cut down
on memory usage I can save money by using less servers.

Curtis j Schofield

unread,
Apr 25, 2011, 9:50:53 PM4/25/11
to bluep...@googlegroups.com


What do the daemons do? - you mention they need the rails environment
- what are they working with?

are they all different environments or the same rails?

Tim Uckun

unread,
Apr 25, 2011, 9:55:14 PM4/25/11
to bluep...@googlegroups.com
>
>
> What do the daemons do? - you mention they need the rails environment
> - what are they working with?

They do all kinds of different things. There are also multiple copies
of them running. They all connect to a message queue and pass messages
back and forth asking for work to be done. So there might be 10
workers of one type and three workers of another type depending on the
load.

>
> are they all different environments or the same rails?

Same rails. They all load the rails environment because they need to
access the models, libs etc of the rails app they are in.

I was thinking of making them not load the rails environment and
instead have them hit the rails server via REST calls but some of the
workers might take a pretty long time. I might still try that approach
but I would have to make sure I have enough concurrency in the rails
app to handle the volume. The volume would be pretty high for sure.

Reply all
Reply to author
Forward
0 new messages