On Wed, Feb 11, 2009 at 9:37 PM, Jason King <jason.brian.k...@gmail.com> wrote: > On Wed, Feb 11, 2009 at 9:24 PM, Martin Bochnig <mar...@martux.org> wrote: >> 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. >
Have you considered using libumem + gcore to get a list of possible culprits? > >> >> >>> 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 >> _______________________________________________ >> perf-discuss mailing list >> perf-discuss@opensolaris.org >> > _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
