Memory usage in reload_services()
Tine Smukavec
valentin.smukavec at hermes.si
Fri Jun 16 14:22:37 GMT 2000
Hello,
we are in troubles with smbd processes which are rapidly growing in terms of
memory usage. We did implement a mean that gives us ability to
dynamically mount or unmount samba shares. I prepared a simple script
which demonstrates this very closely. Script loops following operations:
- touch samba config file to make it newer
- send SIGHUP to smbd process (kill -1 <smbd_pid>)
- connect with smbclient to samba share
- perform a fs operation (e.g. dir)
- disconnect
Script is attached to this mail. Also configuration file is attached.
Next table shows growing rate:
#repetition resident size virtual size
[kb] [kb]
-----------------------------------------------------
0 1584 3152
100 3016 4032
200 3728 4768
300 4576 5640
400 5280 6368
500 6144 7240
600 6792 7976
700 7328 8848
800 7488 9584
900 7920 10456
1000 7824 11192
We examined smbd process with purify tool but found *NO* memory leaks
which would explain the memory growth.
SIGHUP achieves that samba checks if configuration file(s) has changed and
therefore services must be reloaded (function process.c:check_reload()).
Because it is touched right before, samba always decides to reload
services before new connection (function server.c:open_sockets()).
Therefore function server.c:reload_services() is called over and
over again during execution of the script.
We modified reload_services() such that it executes only for
the first time, on all subsequent occurances it just return. With this
modification, process was not growing any more. Then we were moving this
firts time condition down the statements within the function.
It brought us to function call loadparm.c:lp_load(). If we set return
right before lp_load() then memory usage is not growing, but if return is set
after it then memory is growing again.
This is all what we managed to investigate.
The problem is very very urgent for us and I would kindly ask you
to have a look into the matter. I would appreciate at least some
hints in what directions we should proceed in finding the cause of
the problem, if the problem can not be solved immediately by samba team.
I assume that some table is growing without releasing unused elements or
something like that.
We were using samba 1.9.17p4 before migrating to samba 2.0.7 and did
not have any similar problems!
Environment of our test:
------------------------
Server: SunOS lux 5.6 Generic_105181-17 sun4u sparc SUNW,Ultra-4
Samba: 2.0.7
Smbclient: 1.9.17p4
Thank you in advance for any feedback.
Best regards,
Tine.
-------------- next part --------------
#!/usr/bin/ksh
#==============================================================
# Description:
# This script forces samba process to call reload_services()
# over and over again.
#
# Usage: attach <pid>
# <pid> is the pricess id of samba root process
#
# Contributor: Tine Smukavec <valentin.smukavec at hermes.si>
# Updated: June 16, 2000
#==============================================================
#
# customize following variables to match your environment
#
conf_file=#path of smb.conf file
user=#a_user
password=#a_password
server=#a_server
ps_opts=#'-e -o pid -o ppid -o rss -o vsz -o comm'
smb_port=#'-p 10206'
max=1000
i=1
processID=$1
while [ $i -le $max ]
do
echo Pass: $i
echo '===================================='
ps $ps_opts | grep $processID
touch $conf_file
kill -1 $processID
smbclient '\\'$server'\test_share' $password -U $user $smb_port > /dev/null <<EOF
dir
EOF
i=`expr $i + 1`
echo '\n'
done
-------------- next part --------------
[global]
guest account = lmguest
log file = /tmp/samba_test/bubu.%m
lock directory = /tmp/samba_test/lock
character set = iso8859-1
[test_share]
path = /tmp/samba_test
More information about the samba
mailing list