Mykola Maslov wrote: >> Hi everybody, >> >> yesterday I ran 'pkg image-update' on an OpenSolaris running in a >> VirtualBox. The VirtualBox runs on a laptop and serves as a testing >> environment for small programs and reading man pages. So I only >> allocated 512MB of RAM for this machine (no graphical desktop, etc.), >> which is more than enough for this purpose, even with / on ZFS. >> Anyway, the 'pkg image-update' ran for a while and the it looked like >> it got stuck (the spinning dash stopped spinning). So I opened up >> sysstat and saw scanrate being >50k and paging going on like crazy >> with pkg being the only user process currently running. So I took a >> look at prstat and saw pkg was almost consuming 400MB of RAM. >> Hmm - I wouldn't dare calling pkg bloatware, because pkg does a real >> good job and is fast, too, but 400MB of RAM just to determine which >> packages need to be downloaded?! The program wasn't even at the stage >> of installing, it was just creating its plan for update... So it >> really would be nice if it wasn't that hungry for memory. >> >> The workaround on a VirtualBox is of course very easy (just restart >> with more memory). I retried with 900MB and it updated without a >> problem. So that hardens the impression that OpenSolaris needs at >> least one Gig of RAM. >> So maybe it would be worth sending pkg on a diet... Just my $0.02. >> >> Cheers, >> Thomas > > > Yeah, pkg is kinda greedy on ram. In case you are getting not enough > memory during install with pkg, try to increase your swap, or use pkg > without indexing. > > But in general I agree - that`s kinda big memory consuming, though I > don`t know reasons for that, but I belive it`s necessary. >
I went through and put pkg on a diet for build 111; image-update is down to around 200 MB total and pkg install is down around 140 MB. The problem that we were seeing was that all manifests for all installed packages needed to be loaded to determine which directories were disappearing in the new image, and to figure out if any targets of hardlinks were being modified. We now cache this information in separate files and minimize the total ram consumption by deleting manifests from internal caches as soon as possible. This helped a lot w/ both memory consumption and performance. When we revisit the way we store the catalog, we'll recover more RAM. I needed the manifest caching support to allow me to convert the planning to a SAT solver; this is work planned for this summer (post 2009/06). -= Bart -- Bart Smaalders Solaris Kernel Performance barts at cyber.eng.sun.com http://blogs.sun.com/barts "You will contribute more with mercurial than with thunderbird."
