Let me quote myself to keep initial statement here:
---------------------------------------------------------------------------
...
Now most critical part in terms of performance is pkgadd. Because patchadd 
calls pkgadd after it check dependancy (wich pdo doing very well over zones) to 
install delta packages.

We have huge opportunity to bust performance if we get rid of contents file - 
file which has list of all files installed with information about packages etc. 
This file get overwritten twice during package install and contain more then 
60000 records. From engineering point of view I do not see any reason why we 
have this file at all! This is next bottleneck need to be fixed to improve 
installation performance.

I think we should keep this records locally for each package - so 
/var/sadm/pkg/Package should contain contents file with list of files belong to 
this package... In result each time we install package it will not overwrite 
huge contents file twice but instead overwrite small package contents file.

Impact on overall install performance will be unbelivable - after all 
everything we have ends up with pkgadd. Especially patching will benefit 
because patch has number of small delta packages inside and if we have 10 delta 
packages 10K each and now have to 20 times overwrite contents file which is in 
nevada over 1M (way too big in comparison with actual patch size) - you can 
imagine what performance bust we may have if instead of writing 20M will write 
about 100K.

For initial install - simple imagine that for 1000 packages we have in Solaris 
now we save time of overwriting 2000 times 1M contents file - effectevely we 
will write it once - same amount of records but in separate files only once. 
Same for upgrade.

And with zones - let say we have 10 zones X 1000 packages, so for upgrade only 
it will be 20 000 times overwriting 1M contents file! Cool isn't it?
...
-----------------------------------------------------------------------------------
vassun
 
 
This message posted from opensolaris.org

Reply via email to