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