On Sun, Jun 10, 2012 at 11:18:33PM -0700, [email protected] wrote:
> > -C n
> >
> > Specify the number of child images to update in parallel. When
> > recursing into child images (usually zones), update at most n child
> > images in parallel. The default number of child images to update in
> > parallel is 1. If n is 0 or a negative number, all child images are
> > updated in parallel. See also PKG_CONCURRENCY in the "Environment
> > Variables" section.
> >
> >...
> >
> > PKG_CONCURRENCY
> > The number of child images to update in parallel.
> > Ignored if the -C option is specified.
> >
> > When recursing into child images (usually zones), update
> > at most $PKG_CONCURRENCY child images in parallel. If
> > $PKG_CONCURRENCY is 0 or a negative number, all child
> > images are updated in parallel.
> >
> > Default value: 1
>
> I wonder if in the first paragraph (describing -C) or under
> PKG_CONCURRENCY if there should be some guidance on the impact of
> setting a value != 1. Although it's difficult to generalize this, I
> think the obvious concerns are around the memory usage during the plan
> creation (based on the -C value plus the # of packages installed) as
> well as the amount of I/O that will be queued up. Plus I don't know how
> well this would scale on the non-T4 sun4v based system.
in general, the biggest limitation i've seen is memory. (i haven't hit
IO bottlenecks yet, and if you run out of cpu, well then you just
saturate the cpus.)
my observations are about half a gig per zone to do an update. but that
is going to vary significantly depending on how many packages are
installed in the zone and how many publishers are configured. so it's a
little hard to provide guidance.
i could add a sentence saying:
Increasing concurrency will increased memory, cpu, and io
bandwidth consumption, and if set too high could result in poor
system performance.
ed
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
