Time-critical problem at Sun: exploding smbd memory usage

David Collier-Brown davecb at canada.sun.com
Mon Aug 20 13:20:04 GMT 2001


  I have a problem with 2.0.10, which we're getting ready
to do a Sun-wide rollout with.
  2.0.7 on either Solaris or the Qube, the second and all 
subsequent SMBDs are small, and initially all of the same 
size:


 PID USER     PRI  NI  SIZE  RSS SHARE STAT  LIB %CPU %MEM   TIME
COMMAND 
6992 guest-sh  13   0  2624 2624  2348 S       0  0.4  4.1   0:00 smbd
6706 root       0   0  1312 1312   788 S       0  0.0  2.0   0:01 smbd


  2.0.10 on Solaris, on the other hand, has the smbd's RSS (resident
set size) growing  when they're first started, and then they grow 
more during  use. We're primarily concerned with the large initial
growth in RSS as each additional daemon is started, as we may have 
some quite large number of clients per server...

root[csh]@huey[22]# uname -a
SunOS huey 5.8 Generic_108528-03 sun4u sparc SUNW,Ultra-60

On first starting the daemons:

  PID USERNAME THR PRI NICE  SIZE   RES STATE   TIME    CPU COMMAND
  634 root       1   0    0 3112K 1552K sleep   0:00  0.00% smbd

When one connection is made:

  PID USERNAME THR PRI NICE  SIZE   RES STATE   TIME    CPU COMMAND
  667 root       1  58    0 4584K 3536K sleep   0:00  0.23% smbd
  634 root       1  40    0 3112K 1576K sleep   0:00  0.00% smbd


after 2 connections:

  PID USERNAME THR PRI NICE  SIZE   RES STATE   TIME    CPU COMMAND
  671 root       1  58    0 4256K 1984K sleep   0:00  0.03% smbd
  667 root       1  58    0 4584K 3640K sleep   0:00  0.02% smbd
  634 root       1  47    0 3112K 1576K sleep   0:00  0.00% smbd

After 3 connections:
 
  PID USERNAME THR PRI NICE  SIZE   RES STATE   TIME    CPU COMMAND
  667 root       1  58    0 4584K 3672K sleep   0:00  0.00% smbd
  671 root       1  58    0 4584K 2656K sleep   0:00  0.00% smbd
  681 root       1  58    0 4584K 2576K sleep   0:00  0.12% smbd
  634 root       1  48    0 3112K 1576K sleep   0:00  0.03% smbd

  This is a risk issue for us, because we sized the systems based 
on masurements done with 2.0.7, then applied the bugfixes by rolling'
forward to 2.0.10.  
  It looks rather as if the fix in 2.0.9/10 has a memory leak:

  I've looked at 2.0.10, but I don't see why there should be a
problem...  could the authors of the security fixes help us out
with this, please?

--dave
--
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