On 11/4/07, John-Paul Drawneek <[EMAIL PROTECTED]> wrote:
> I have got apache2 in a zone
> capped-memory:
>         physical: 512M
>         [swap: 2G]
>         [locked: 100M]
> rctl:
>         name: zone.max-locked-memory
>         value: (priv=privileged,limit=104857600,action=deny)
> rctl:
>         name: zone.max-swap
>         value: (priv=privileged,limit=2147483648,action=deny)
>
> I have got real helixserver in a zone
> capped-memory:
>         physical: 512M
>         [swap: 1G]
>         [locked: 150M]
> rctl:
>         name: zone.max-locked-memory
>         value: (priv=privileged,limit=157286400,action=deny)
> rctl:
>         name: zone.max-swap
>         value: (priv=privileged,limit=1073741824,action=deny)
>
> box has got 1280mb of ram - all should be good (ok to my limited knowledge)
>
> apache2 gets huge - helixserver stops streaming - reset apache2 helix server 
> starts again.
>
> ideas on what evils apache2 is doing?
> Or a way to find out what resource helix server needs?

By having the max swap (3 GB) larger than your physical memory (1.2
GB), as the processes grow in memory usage, they will start to page.
Heavy paging will slow the box down tremendously, to the point where
performance sharply degrades.  Under enough contention, it is quite
possible for this degradation to cause processes to pause for many
seconds or longer.

I just today noticed that pmap has a -S option to show swap
reservations.  Perhaps this will be helpful.

I suspect that what you really need to do is one of the following:

1) Set the swap limit on Apache to something much closer to 512MB.
Probably a good idea to set the swap limit for Helix closer the the
physical as well.
2) Install another 2 GB of RAM.

Paging to swap devices is evil.  Workloads that need more memory than
you have physical RAM for their working set will not give suitable
interactive performance (and even batch performance would be
miserable).

-- 
Mike Gerdts
http://mgerdts.blogspot.com/
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org

Reply via email to