Samba 2.0.7 Memory Bloat under Sparc Solaris 5.8
David Collier-Brown
David.Collier-Brown at canada.sun.com
Wed Aug 30 15:46:49 GMT 2000
travis at deakin.edu.au wrote:
> A typical 2.0.6 smbd process for us is 4 meg in size.. a 2.0.7 smbd process
> grows to 190 meg in size over a period of seconds. This then very quickly
> exhausts the ram resources of the servers this is tested on.
>
> If I comment out the [printers] section from smb.conf then the proces size
> of smbd (2.0.7) drops to 880k.
Ok, that's bad (;-)) Let me put my Solaris hat on...
> We have approximately 2000 printers in our print cap, we run lprng.
>
> I tried numerous things including making a new printcap which only
> listed the names of the printers without any of the printcap junk in there
> and the problem still persisted.
>
> The sparc box's are fully patched, I tried both Sun Workshop 5 and gcc
> with the same results displayed under both.
You (and the team) can see memory usage with /usr/bin/pmap
and application behavior with truss/apptrace.
Run pmap against smbd, and you should get something
resembling the following:
$ pmap 1364
1364: (dns helper)
00010000 13072K read/exec
/usr/dist/share/netscape,v4.51/5bin.sun4/netscape
00CE2000 984K read/write/exec
/usr/dist/share/netscape,v4.51/5bin.sun4/netscape
00DD8000 416K read/write/exec [ heap ]
FEDA0000 16K - [ anon ]
FEDA4000 128K read/write/exec [ anon ]
FEDC4000 16K - [ anon ]
FEDD0000 16K read/exec
/usr/platform/sun4u/lib/libc_psr.so.1
FEDE0000 16K read/exec /usr/lib/libmp.so.2
FEDF4000 8K read/write/exec /usr/lib/libmp.so.2
FEE00000 664K read/exec /usr/lib/libc.so.1
FEEB6000 24K read/write/exec /usr/lib/libc.so.1
FEEBC000 8K read/write/exec /usr/lib/libc.so.1
FEED0000 80K read/exec /usr/openwin/lib/libICE.so.6
FEEF4000 8K read/write/exec /usr/openwin/lib/libICE.so.6
FEEF6000 8K read/write/exec /usr/openwin/lib/libICE.so.6
FEF00000 32K read/exec /usr/openwin/lib/libSM.so.6
FEF18000 8K read/write/exec /usr/openwin/lib/libSM.so.6
FEF20000 88K read/exec /usr/lib/libm.so.1
FEF44000 8K read/write/exec /usr/lib/libm.so.1
FEF50000 56K read/exec
/usr/dist/share/netscape,v4.51/lib/libresolv.so.2
FEF6C000 8K read/write/exec
/usr/dist/share/netscape,v4.51/lib/libresolv.so.2
FEF6E000 16K read/write/exec
/usr/dist/share/netscape,v4.51/lib/libresolv.so.2
FEF80000 552K read/exec /usr/lib/libnsl.so.1
FF01A000 32K read/write/exec /usr/lib/libnsl.so.1
FF022000 32K read/write/exec /usr/lib/libnsl.so.1
FF030000 8K read/write/exec [ anon ]
FF040000 8K read/write/exec [ anon ]
FF060000 40K read/exec /usr/lib/libsocket.so.1
FF07A000 8K read/write/exec /usr/lib/libsocket.so.1
FF080000 560K read/exec /usr/openwin/lib/libX11.so.4
FF11C000 24K read/write/exec /usr/openwin/lib/libX11.so.4
FF130000 96K read/exec /usr/openwin/lib/libXext.so.0
FF158000 8K read/write/exec /usr/openwin/lib/libXext.so.0
FF160000 80K read/exec /usr/openwin/lib/libXmu.so.4
FF184000 8K read/write/exec /usr/openwin/lib/libXmu.so.4
FF190000 336K read/exec /usr/openwin/lib/libXt.so.4
FF1F4000 24K read/write/exec /usr/openwin/lib/libXt.so.4
FF1FA000 8K read/write/exec /usr/openwin/lib/libXt.so.4
FF200000 1400K read/exec
/usr/dist/share/netscape,v4.51/lib/libXm.so.3
FF36C000 136K read/write/exec
/usr/dist/share/netscape,v4.51/lib/libXm.so.3
FF38E000 8K read/write/exec
/usr/dist/share/netscape,v4.51/lib/libXm.so.3
FF3A0000 8K read/write/exec [ anon ]
FF3B0000 8K read/exec /usr/lib/libdl.so.1
FF3C0000 128K read/exec /usr/lib/ld.so.1
FF3E0000 8K read/write/exec /usr/lib/ld.so.1
FFBEA000 24K read/write/exec [ stack ]
total 19224K
This happends to be netscape, plus all the
shared libraries it uses. The read/exec
areas are code, read/write/exec areas are data.
Run it again, against smbd with the printers
share turned on, and mail me/us the two results:
that will tell us how much more space is used,
and where (It's probably going to be in the heap).
Next, kill your smbd and restart it under truss and
apptracee, from the command-line. The commands are:
truss -f -l -d -o truss.out /path/to/smbd -D
and
apptrace -f -d apptrace.out /path/to/smbd -D
Mail me the .out files and I'll extract the data
for the list as soon as it comes in. {I'm a Solaris
performance guy, and this is a Solaris memory performance
issue, so...]
--dave
--
David Collier-Brown, | Always do right. This will gratify some people
185 Ellerslie Ave., | and astonish the rest. -- Mark Twain
Willowdale, Ontario | //www.oreilly.com/catalog/samba/author.html
Work: (905) 415-2849 Home: (416) 223-8968 Email: davecb at canada.sun.com
More information about the samba-technical
mailing list