[Samba] Ways to make "smbd" use less memory?

Jeremy Allison jra at samba.org
Tue Mar 31 16:41:31 UTC 2020


On Tue, Mar 31, 2020 at 03:58:49PM +0200, Peter Eriksson via samba wrote:
> I’m looking for ways to make a “smbd” daemon use less memory. Typically on our system each process uses 160-200MB virtual memory with ~120-140MB as RSS. Now with ~1400 such processes (and clients connected) this uses a lot of memory… Even though some may be shared. It doesn’t look like a memory leak though since it’s pretty stable at those levels. But it still feels pretty bloated...
> 
> This particular server has 256GB RAM right now but will have more added.
> 
> I’m not sure exactly where all this memory is used but I think the fact that our AD has 130,000 users (not all active) and a gazillion groups (but just a few (~2000) with “gidNumber” set) contributes a bit to it. 
> 
> 
> Any suggestions on ways to trim this would be welcome.
> 
> > # ps auxdwwww
> > USER       PID   %CPU %MEM    VSZ    RSS TT  STAT STARTED        TIME COMMAND
> > ...
> > root     30577    0.3  0.0 159492 117936  -  Ss   07:00       2:55.80 |-- /liu/sbin/smbd --daemon --configfile=/liu/etc/samba/smb.conf
> > root     98861    7.8  0.1 172628 135424  -  S    13:54       0:01.56 | |-- /liu/sbin/smbd --daemon --configfile=/liu/etc/samba/smb.conf
> > rodro16  30602    0.6  0.1 192128 143028  -  S    07:00       4:28.45 | |-- /liu/sbin/smbd --daemon --configfile=/liu/etc/samba/smb.conf
> > gorra80  37534    0.6  0.1 201744 147004  -  S    12:13       0:00.33 | |-- /liu/sbin/smbd --daemon --configfile=/liu/etc/samba/smb.conf
> > kerjo10  35974    0.5  0.1 203952 142024  -  S    07:03       0:01.42 | |-- /liu/sbin/smbd --daemon --configfile=/liu/etc/samba/smb.conf
> > marma13  47632    0.4  0.1 205100 170616  -  S    07:10       0:16.69 | |-- /liu/sbin/smbd --daemon --configfile=/liu/etc/samba/smb.conf
> > poasa83  93542    0.1  0.1 199500 156160  -  S    13:49       0:00.51 | |-- /liu/sbin/smbd --daemon --configfile=/liu/etc/samba/smb.conf
> > vinya32  98774    0.1  0.1 201460 135048  -  S    13:53       0:00.09 | |-- /liu/sbin/smbd --daemon --configfile=/liu/etc/samba/smb.conf
> > root       174    0.0  0.1 186616 137720  -  I    07:43       0:00.12 | |-- /liu/sbin/smbd --daemon --configfile=/liu/etc/samba/smb.conf
> > root       226    0.0  0.1 204168 140004  -  S    07:43       0:01.21 | |-- /liu/sbin/smbd --daemon --configfile=/liu/etc/samba/smb.conf
> > root       227    0.0  0.1 184724 138456  -  S    07:43       0:01.11 | |-- /liu/sbin/smbd --daemon --configfile=/liu/etc/samba/smb.conf
> > root       228    0.0  0.1 201652 150152  -  S    07:43       0:03.73 | |-- /liu/sbin/smbd --daemon --configfile=/liu/etc/samba/smb.conf
> > root       261    0.0  0.1 196656 143840  -  I    11:50       0:00.08 | |-- /liu/sbin/smbd --daemon --configfile=/liu/etc/samba/smb.conf
> > root       334    0.0  0.1 201380 140928  -  I    11:51       0:00.80 | |-- /liu/sbin/smbd --daemon --configfile=/liu/etc/samba/smb.conf
> > root       361    0.0  0.1 199468 153156  -  I    11:51       0:01.39 | |-- /liu/sbin/smbd --daemon --configfile=/liu/etc/samba/smb.conf
> 
> 
> Looking at the memory allocation output (procstat -v on a FreeBSD machine, a test server with not much activity) on a master “smbd” with VSZ 160MB and RSS 117 it looks like 102MB of it is allocated memory (the rest is shared libraries) spread out as:
> 
> Size			Allocations
>      4096		8868	4K * 88868 = 36MB
>       8192		1
>      16384		1
>      32768		1
>      45056		1
>      49152		2
>      73728		1
>     135168	1
>     143360	1
>     180224	1
>     270336	1
>     544768	1
>    2093056	16	2*16 = 	32 MB
>    2097152	12	2*12 =	24 MB
>    6291456	1	 		6 MB
> 
> Since this is on the master smbd then it’ll be inherited by the ones it forks off too.

Does this included the mmap'ed tdb databases ?

If so it's probably not as bad as it looks.

Is there a way you can split this out to
see filenames of mmap'ed regions ?

The other thing to do is use smbcontrol to
query the named or unnamed talloc allocations
(we keep track of them all).



More information about the samba mailing list