Local work-around for Samba memory leak problem (longish)

[Keith Farrar]

Nope, no printer shares defined, just lots of disk shares.

The problem crops up under 2.0.9, 2.2.0, and 2.2.X (CVS as of last week)
under Solaris 2.6 & Solaris 8.

I'm not running a Linux box with lots of shares, so I don't know if will
strike there as well.

Should be simple to test for the leak's existence: create smb.conf with a
couple thousand disk shares, and watch the process growth over time. Then
rebuild with a memory leak detector of some form and debug.

Simple in principle, but more complicated in practice. :)

Update (minor testing, without code reading/debugging):
 Created 2000 disk shares on a Red Hat Linux 7.1 box (has more memory &
faster cpu than my desktop SPARC box). Installed Samba 2.2 from CVS,
retrieved with "cvs update -rSAMBA_2_2_RELEASE". Started smbtorture on
another Linux box (50 clients, SMBTORTURE test, 10 operations per client,
repeat 2000 times...). Parent smbd process seemed stable at 9.9 MB (after
a few thousand connections). To simulate our production environment (where
smb.conf includes a frequently changing, script-generated local.smb.conf
fle), a cron job touches the smb.conf file each minute. The Linux parent
is still pretty stable (at 11 MB), but its children are growing (so far,
they've grown to 20 MB).

Maybe the problem appears in running daemons which detect a change to
smb.conf and re-read it (and any files smb.conf includes).

Question (since I've been asked a couple times about printing):
 Does smbd re-scan smb.conf or the printer list (e.g. printcap file)
frequently if printer shares are enabled?



> Date: Wed, 30 May 2001 15:43:15 PDT
> From: Gerald Carter <gcarter at valinux.com>
> To: samba-technical at samba.org
> Subject: Local work-around for Samba memory leak problem (fwd)
>
> [Moved to Samba-technical...]
>
> Keith,
>
> What version of Samba are you running?  Do you have a large printcap with
> 'load printers = yes'?
>
> jerry
>
>
> ---------- Forwarded message ----------
> Date: Wed, 30 May 2001 15:11:10 PDT
> From: Keith Farrar <farrar at parc.xerox.com>
> To: samba at lists.samba.org
> Subject: Local work-around for Samba memory leak problem
>
> The problem:
>  Samba's smbd processes grow until they exhaust memory on our servers. The
> process size and growth appears proportional to the number of volume share
> definitions. One server has around 900 shared volumes, and its mate has
> around 1500 (one for each NFS automounter map entry which refers to the
> server). The standard Samba startup procedure used one master smbd daemon
> which spawned a new child process for each new connection. Unfortunately,
> the master daemon grows larger with time, leading its children to rapidly
> exhaust virtual memory (as each child process inherits the full memory
> footprint of its expanding parent). These small SPARC Solaris servers each
> have 1 GB of RAM and 1 GB of swap space. They were running low on memory
> (requiring smbd stop/start) one to four times per day.
>
> I'm drowning in other work, so I haven't intrumented a running daemon with
> a memory leak detector. But I needed to slow the rate of consumption so
> that the servers continue to serve files and mail to their (500) clients.
>
> The work-around:
>  Install the xinetd service on the servers.
>  Impose 25 MB limit on heap size in daemon startup environment (daemon
>   will need around 10 MB, minimum, to run with 1500 shares).
>  Start xinetd with smbd (netbios-ssn) service as its only enabled entry.
>
> End result:
>  Processes are killed by the kernel when they get too large (>25 MB), and
> the windows clients's automatic reconnection will spawn replacements.
>
>
> | Keith Farrar | Xerox PARC CSNS | Palo Alto, CA | 650-812-4292 |
> | DOMAIN:  farrar at parc.xerox.com |                              |
>

-- 
| Keith Farrar | Xerox PARC CSNS | Palo Alto, CA | 650-812-4292	|
| DOMAIN:  farrar at parc.xerox.com |				|