[Samba] gencache.tdb growing and growing and...

[Peter Eriksson]

Is it normal that the gencache.tdb should grow and grow “forever” and fill up with “RA/<hex>” posts?

I’ve been investigating why our Samba 4.7.3 servers (happened with older version 4 servers too) would use such insane amounts of memory on our FreeBSD 11.1 servers (we see smbd processes using hundreds of megabytes of RAM and up to 5GB virtual memory).

Anyway, one part that seems to use over 100MB of memory is the (shared) gencache.tdb database. So I looked at what was stored inside gencache.tdb on of the busy servers and noticed that it contained:

> # tdbtool gencache.tdb check
> Database integrity is OK and has 495309 records

> # tdbtool gencache.tdb keys | egrep IDMAP/ | wc -l
>    88974
> # tdbtool gencache.tdb keys | egrep RA/ | wc -l
>   406311

(The number of IDMAP records I sort of can understand - our AD server contains some 100k users). But 406k RA records?

> # tdbtool gencache.tdb dump | egrep -A4 RA/ | sed -e 's:/: :' | awk '($1 == "[000]") {print $20}'|sort|uniq -c
> 2001 OSX
> 374245 Sam
> 30080 Vis

(“VIs” = Vista, “Sam” = Samba). 374245 “Samba” records seems a bit excessive. Our servers are mostly serving Windows 7 and Windows 10 clients. The most active “Samba” clients should be our Nagios monitoring system...

I deleted the gencache.tdb on a test server and restarted Samba, and it starts out low and then slowly keeps on growing. The only client that connects is the monitoring system.

An “RA” records leak or is this by design and every new client connection gets a new record?

In source3/lib/util.c there is a "#define RA_CACHE_TTL 7*24*3600” - a week, but are the keys really removed at all? Due to the huge smbd processes we started restarting the Samba processes every night, could this prevent any kind of garbage collection routine from running?

—
[Lı.U] System Administrator ITI-NET IT.LiU.SE +46-13-28 2786