Hi! On Thu, Feb 12, 2009 at 4:05 AM, Bob Friesenhahn <bfrie...@simple.dallas.tx.us> wrote:
> Your 'top' program obviously has some sort of bug but otherwise I don't see > anything necessarily out of the ordinary in the top listings. Does this explain why a wget process grew to 2.2GB (where I killed it) ?? Then wget must have exactly the same bug, which is unlikely. Therefore the bug must be in a shared lib which both use. This suggests (but is not limited to) libc. > Some releases > of top work much better under Solaris than others. Top is a very handy tool > but neither 'SIZE' or 'RES' is indicative of a problem. For example 'SIZE' > is increased by simply memory mapping a file or device since it is based on > the number of allocated virtual memory pages. Virtual memory pages may be > shared between processes. RES is a bit more useful since it indicates the > amount of those virtual memory pages which are mapped into RAM, but it is > also misleading since pages may remain mapped into RAM due to lack of > pressure for memory (from other processes) as well as pressure from memory > from the running process. Yes. But I also checked with a csw-version of top. I decided, however, to attach screenshots depicting the version of top which ships as part of SXCE, as reference (because it has probably been ARC-reviewed and co-checked a 100 times). > If you want to learn more about how memory is > being used by a Solaris process, then see 'pmap'. Okay, let me read its man page. But first, here is its current output for one of the still running wget processes: # pmap 11017 11017: wget -m -p -k www.opensolaris.org 11017: wget -m -p -k www.opensolaris.org 08045000 12K rw--- [ stack ] 08050000 208K r-x-- /usr/bin/wget 08093000 20K rwx-- /usr/bin/wget 08098000 553652K rwx-- [ heap ] FEB10000 64K rwx-- [ anon ] FEB23000 4K rwxs- [ anon ] FEB30000 24K rwx-- [ anon ] FEB40000 1276K r-x-- /usr/lib/libc/libc_hwcap2.so.1 FEC8F000 32K rwx-- /usr/lib/libc/libc_hwcap2.so.1 FEC97000 8K rwx-- /usr/lib/libc/libc_hwcap2.so.1 FECA0000 4K rwx-- [ anon ] FECB0000 1276K r-x-- /lib/libcrypto.so.0.9.8 FEDFF000 88K rw--- /lib/libcrypto.so.0.9.8 FEE15000 12K rw--- /lib/libcrypto.so.0.9.8 FEE20000 264K r-x-- /lib/libssl.so.0.9.8 FEE72000 16K rw--- /lib/libssl.so.0.9.8 FEE80000 624K r-x-- /lib/libnsl.so.1 FEF2C000 24K rw--- /lib/libnsl.so.1 FEF32000 20K rw--- /lib/libnsl.so.1 FEF40000 56K r-x-- /lib/libsocket.so.1 FEF5E000 4K rw--- /lib/libsocket.so.1 FEF70000 4K rwx-- [ anon ] FEF80000 4K r-x-- /lib/libdl.so.1 FEF90000 4K r-x-- /lib/libmd5.so.1 FEFA0000 4K r-x-- /lib/libintl.so.1 FEFB0000 4K rwx-- [ anon ] FEFBD000 184K r-x-- /lib/ld.so.1 FEFFB000 8K rwx-- /lib/ld.so.1 FEFFD000 4K rwx-- /lib/ld.so.1 total 557904K # So, as you can see it has 545MB on Heap. > It does seem a bit unusual that any swap is used at all. Double check to > make sure that you have not copied a bunch of large files to /tmp since /tmp > comes out of the total memory/swap budget. Sure, thanks. But of course I don't use /tmp for storing big files anymore (as this box has 2.4 TB of ZFS storage). And also no big file got stored there by FireFox's download manager or stuff like that. Proof: bash-3.2$ du -h /tmp 12K /tmp/.removable 4K /tmp/hsperfdata_root 4K /tmp/.X11-unix 4K /tmp/.X11-pipe 36K /tmp/hsperfdata_noaccess 28K /tmp/plugtmp-1 4K /tmp/.ICE-unix 4K /tmp/fam-martin 4K /tmp/x 8K /tmp/plugtmp 4K /tmp/hsperfdata_martin 4K /tmp/65535_sun_studio_12 4K /tmp/plugtmp-2 8K /tmp/plugtmp-3 8K /tmp/.vbox-martin-ipc 8K /tmp/plugtmp-4 31M /tmp bash-3.2$ > Perhaps the algorithm that 'wget' uses requires a lot of memory to keep > track of things, or perhaps the version you are using has a memory leak. > > Bob I use the default versions shipping with SXCE (/usr/bin/top and /usr/sfw/bin/wget) Both my version of wget shall have a bug and my version of top? Seriously, how likely is this? Isn't it more likely that there is a problem in a shared library that both happen to use? %martin _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
