Patchadd performance
Tim Bradshaw
can see that it's probably being ultra-paranoid about backout etc, but
it's still just incredibly slow: in many cases it must be faster to
reinstall than patch.
Is there anything easy that can be done to speed up patchadd?
--tim
Geoff Lane
> Is there any simple reason why patching Solaris takes *so* long? I
> can see that it's probably being ultra-paranoid about backout etc, but
> it's still just incredibly slow: in many cases it must be faster to
> reinstall than patch.
It is very careful not to leave the system in an unstable state.
> Is there anything easy that can be done to speed up patchadd?
Don't let uninstalled patches build up :-) With smpatch and updatemanager,
you can apply most patches to a live system.
Casper Dik used to maintain a fastpatch utility which was much faster than
the official method. See ftp://ftp.science.uva.nl/pub/solaris/auto-install/
I've never used it, and with zones and other Solaris developments, it may no
longer be appropriate.
Tim Bradshaw
>
> It is very careful not to leave the system in an unstable state.
I'm sure it is. But it could write things to paper tape faster than
it runs.
>
> Don't let uninstalled patches build up :-) With smpatch and updatemanager,
> you can apply most patches to a live system.
That is not an option for any kind of change controlled environment
(neither one) unfortunately.
> Casper Dik used to maintain a fastpatch utility which was much faster than
> the official method. Seeftp://ftp.science.uva.nl/pub/solaris/auto-install/
> I've never used it, and with zones and other Solaris developments, it may no
> longer be appropriate.
Thanks, I'll look at that. I'm not actually sure that patchadd is
appropriate for machines with zones :-). I'm kind of hoping that they
will fix live upgrade again: it is a good answer, but you can't
realistically use it for 9-10 upgrades (won't apply patches) or 10
with zones. I guess almost no one uses it (and the implementation is
probably a horror) so it must have seemed like something it was OK to
not keep working. (Of course the people who *do* use it probably
correlate well with those who buy large numbers of high-end systems,
but that kind of argument is a bit subtle...)
--tim
Ian Collins
>
> Thanks, I'll look at that. I'm not actually sure that patchadd is
> appropriate for machines with zones :-). I'm kind of hoping that they
> will fix live upgrade again: it is a good answer, but you can't
> realistically use it for 9-10 upgrades (won't apply patches) or 10
> with zones.
It should, it has worked in Express for ages, so it should work for U3
and U4.
--
Ian Collins.
Tim Bradshaw
> Tim Bradshaw wrote:
> It should, it has worked in Express for ages, so it should work for U3
> and U4.
Not in u3. Dunno about u4 yet, obviously (though there are rumours).
Presumably the issue is that the whole boot-the-zone-to-patch it thing
is not going to work too well if that zone is on a BE which is not
itself active.
Daniel Rock
> Is there any simple reason why patching Solaris takes *so* long?
Problematic are jumbo patches, and with Solaris 10 patches to
Python, PostgreSQL, etc. if they upgrade the package to a newer release
For instance a PostgreSQL patch has to remove all files in
/usr/share/doc/pgsql/8.1.x and other locations (almost 1000) via removef
manually. Each invocation of removef rewrites /var/sadm/install/contents
completely. This file is on my machine almost 30MB large. So during
patching of PostgreSQL over 20GB is written just to
/var/sadm/install/contents.
You can try the following at the risk of corrupting the package database
(which could be manually correctable) if the machine crashes during
patchadd:
cp -p /var/sadm/install/contents /tmp/contents
mount -F lofs /tmp/contents /var/sadm/install/contents
[patchadd]
umount /var/sadm/install/contents
cp -p /tmp/contents /var/sadm/install/contents
Patching should now be faster since everything written to
/var/sadm/install/contents should now be written to tmpfs.
--
Daniel
Tim Bradshaw
>
> For instance a PostgreSQL patch has to remove all files in
> /usr/share/doc/pgsql/8.1.x and other locations (almost 1000) via removef
> manually. Each invocation of removef rewrites /var/sadm/install/contents
> completely. This file is on my machine almost 30MB large. So during
> patching of PostgreSQL over 20GB is written just to
> /var/sadm/install/contents.
Ah that makes sense. They need some kind of transaction, so they can
batch up changes and apply them all at once (with a log so if
something dies they can roll the log in).
--tim
Ian Collins
http://docs.sun.com/app/docs/doc/817-0547/gdstw?a=view
--
Ian Collins.