Service vs. AMI vs. instance vs. process

5 views
Skip to first unread message

shlomo

unread,
Aug 13, 2008, 9:36:11 AM8/13/08
to lifeguard-dev
How can I use lifeguard to efficiently manage services that require
less CPU than a full EC2 c1.small instance? I want to maximize the use
of every CPU I'm paying for.

For example, say the service uses 1/5th of an instance's CPU. I can
build an AMI to launch 5 JVMs running the same service. If I
understand lifeguard correctly (and I could be wrong), these process'
services will share work and status queues, and the lifeguard pool
manager will not be able to differentiate between processes.
Nevertheless, might this setup actually work in practice?

And what about having multiple *different* services running on a
single instance - how do I do this with lifeguard?

Thanks.

.. Shlomo

David Kavanagh

unread,
Aug 13, 2008, 9:46:49 AM8/13/08
to lifegu...@googlegroups.com
I think you are right about that. I've thought about it before and if
you run 2 (or 3 or 4) instances of the service on your EC2 instance,
that host will just have higher effective throughput. I think
lifeguard will still manage those kinds of instances just fine.

David

David Kavanagh

unread,
Aug 13, 2008, 9:48:25 AM8/13/08
to lifegu...@googlegroups.com
Oh, The down-side to this is that there will be multiple pool status
messages send to the pool manager from that instance. Each will report
a certain "busyness". I think it will still work, and scaling will
happen.

David

shlomo

unread,
Aug 13, 2008, 9:56:59 AM8/13/08
to lifeguard-dev
Right. And if one of the processes gets "stuck" (fatal error or
whatever) then the total effective throughput of that instance should
drop proportionately, dropping to zero only when no more messages
remain in the work queue or all of the processes get "stuck".

Now, how about running multiple different services on the same EC2
instance? Can lifeguard manage these services too?

On Aug 13, 4:48 pm, "David Kavanagh" <dkavan...@gmail.com> wrote:
> Oh, The down-side to this is that there will be multiple pool status
> messages send to the pool manager from that instance. Each will report
> a certain "busyness". I think it will still work, and scaling will
> happen.
>
> David
>
> On Wed, Aug 13, 2008 at 9:46 AM, David Kavanagh <dkavan...@gmail.com> wrote:
> > I think you are right about that. I've thought about it before and if
> > you run 2 (or 3 or 4) instances of the service on your EC2 instance,
> > that host will just have higher effective throughput. I think
> > lifeguard will still manage those kinds of instances just  fine.
>
> > David
>

David Kavanagh

unread,
Aug 13, 2008, 10:12:16 AM8/13/08
to lifegu...@googlegroups.com
I think different services on the same EC2 instance would get
confusing. If you had a main service running, and some minor
supporting service also running, that might work better (because
lifeguard could manage that instance based on the major service that
took most of the CPU).
I don't remember if it was you or someone else, but the idea of
running the JVM (lifeguard service) from a script, but using a while
loop to make sure if the JVM exited that the service would come back
up quickly is a good one. That would just improve the robustness. I
used to do this on a Java based Kiosk I worked on years ago.

David

shlomo

unread,
Aug 13, 2008, 11:48:21 AM8/13/08
to lifeguard-dev
Is there any way to get lifeguard to monitor the status of such
services (different services sharing the same instance)? Perhaps it
might work if we don't let lifeguard create/destroy instances?

For example, is there a way to start the services manually and then
somehow notify lifeguard of their existence/queues/unique-ids ?

I know lifeguard can discover existing AMI-based service instances,
but that's different.

.. Shlomo
Reply all
Reply to author
Forward
0 new messages