Time-critical problem at Sun: exploding smbd memory usage

David Collier-Brown davecb at canada.sun.com
Mon Aug 20 19:09:10 GMT 2001

Gerald Carter wrote:
> On Mon, 20 Aug 2001, David Collier-Brown wrote:
> > Gerald Carter wrote:
> > > Strange.  There were no major changes between 2.0.7 and 2.0.10.  Only
> > > security fixes.  Does the memory usage flatline out after a while?
> > > I normally see 4.5Mb for the RSS for running smbd on Solaris 2.6 - 8.
> >
> >       Yes, it flattens out, with a claimed size of 17MB, and
> >       RSS of 15 (if prstat is to be beleived!).
> Ewww.. Ummm....That's not good :-(  Can you give any more details?
> smb.conf?  Homes?  # of shares?  etc...

	Four main shares: homes, printers, /net and /usr/dist

	The globals are:
        workgroup = AUS
        netbios name = homer
        server string = Samba %v, ITsamba v1.1 on %L
        encrypt passwords = no
        password level = 4
        log level = 1
        time server = Yes
        os level = 200
        max log size = 8000
        preferred master = no
        domain master = no
        wins support = no
        wins server = famine.aus
        wins proxy = Yes
        guest account = samba
        local master = no
        name resolve order = host wins bcast 
        dns proxy = yes 
        preserve case = yes
        short preserve case = yes
        default case = lower
        printcap name = lpstat
        printing = sysv
        load printers = yes
        security = user
        socket options = TCP_NODELAY
        lpq cache time = 0
        map to guest = Bad User
        interfaces = hme0 hme1 
        bind interfaces only = yes

The process map looks like this:
# pmap 3886, where 3386 is the smbd serving my smbclient

3886:   /opt/samba/sbin/smbd -D -l /var/log/samba/2001-08-17.log.smb
00010000    808K read/exec         /opt/samba/sbin/smbd
	the program's excutables
000E8000    240K read/write/exec   /opt/samba/sbin/smbd
	the progam's globals
00124000  13360K read/write/exec     [ heap ]
	this, as you might expect, is where the space
	is used up.

FF000000   1024K read/write/exec/shared  [ shmid=0x771 ]
	a shared memory area

FF120000     24K read/exec         /usr/lib/nss_files.so.1
FF136000      8K read/write/exec   /usr/lib/nss_files.so.1
	and a bunch of shared library code and global data...
FF140000     24K read/exec         /usr/lib/nss_nis.so.1
FF156000      8K read/write/exec   /usr/lib/nss_nis.so.1
FF160000     16K read/exec         /usr/lib/nss_compat.so.1
FF174000      8K read/write/exec   /usr/lib/nss_compat.so.1
FF180000    672K read/exec         /usr/lib/libc.so.1
FF238000     24K read/write/exec   /usr/lib/libc.so.1
FF23E000      8K read/write/exec   /usr/lib/libc.so.1
FF250000     16K read/exec        
FF260000     16K read/exec         /usr/lib/libmp.so.2
FF274000      8K read/write/exec   /usr/lib/libmp.so.2
FF280000    552K read/exec         /usr/lib/libnsl.so.1
FF31A000     32K read/write/exec   /usr/lib/libnsl.so.1
FF322000     32K read/write/exec   /usr/lib/libnsl.so.1
FF330000      8K read/write/exec     [ anon ]
FF350000     40K read/exec         /usr/lib/libsocket.so.1
FF36A000      8K read/write/exec   /usr/lib/libsocket.so.1
FF370000      8K read/exec         /usr/lib/libsec.so.1
FF382000      8K read/write/exec   /usr/lib/libsec.so.1
FF390000      8K read/exec         /usr/lib/libdl.so.1
FF3A0000      8K read/write/exec     [ anon ]
FF3B0000    136K read/exec         /usr/lib/ld.so.1
FF3E2000      8K read/write/exec   /usr/lib/ld.so.1
FFBEA000     24K read/write/exec     [ stack ]
 total    17136K

The parent smbd is almost the same, but without the
and /usr/lib/nss_compat.so.1 libraries and no shared memory area.

We have enough swap and real memory that a workaround is
possible, but the growth is disquieting (;-))

David Collier-Brown,           | Always do right. This will gratify 
Performance & Engineering Team | some people and astonish the rest.
Americas Customer Engineering  |                      -- Mark Twain
(905) 415-2849                 | davecb at canada.sun.com

More information about the samba-technical mailing list