On 04/28/10 02:25, Jimmo wrote:
Hi folks,
I'm wondering if recent improvements and plans to reduce client
memory consumption could help define a minimum memory constraint,
i.e. "one must have at least xxMB of memory" or similar? This would
be useful for users of zones with memory caps who want to use
pkg within the zone - or is the advice simply not to do this and
instead do "pkg -R<zone_root> <command>" in the global zone?
Of course, it's not just about zones, I guess it could apply
to embedded environments with small memory configs, it was
just that the zones example was how the question came up...
Background:
A handy feature of zones is that the overhead of the zone
itself is remarkably lightweight, meaning that one can do
quite a lot with relatively little overhead (i.e. a basic
apache2 zone can serve casual traffic to a simple web
site in<80MB memory and ~0.1% cpu). Great!
A customer at a recent Oracle welcome event was telling me
how they provision zones as "virtual private servers" and
use resource caps as pricing differentials...an entry
level virtual private server product being a simple hosting
zone with a 128MB memory cap, more than enough for apache2
and your average home user/cottage industry web site.
Occasionally, it may be necessary to install additional
s/w in the zone and it seems that running "pkg install" in
a zone with a memory cap of<512MB often fails due to
virtual memory starvation, at least up to and including
build 134.
I realize that getting pkg to cope with tight memory
constraints like this may not be practical, or it could
be that the performance trade-off would be unacceptable.
I'm just wondering what the current thinking is on this?
At this point in time we're not ready to specify a memory cap.
The code today consumes RAM in proportion to the amount of
installed software; if you install a large number of packages
on a machine with a arbitrarily small amount of memory, problems
ensue. Python (like most interpreted, GC'd languages) does
not perform well when virtual size > physical memory, due to
LRU behavior of page scanner and GC interacting nearly
pessimally.
As has been discussed here several times, reducing the peak
memory consumption of pkg is one of the items on our list of
things to do. However, the design center for pkg will never
be installing all of Solaris in tiny amount of virtual or
physical memory. Those expecting such will likely be
disappointed.
- Bart
--
Bart Smaalders Solaris Kernel Performance
[email protected] http://blogs.sun.com/barts
"You will contribute more with mercurial than with thunderbird."
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
