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
Hi, Peter! I'm curious do you use stock FreeBSD with the self-compiled Samba or some FreeBSD-based appliance? As Samba 4.7 port did hit the ports collections only recently and comes with various extra patches. With regards, Timur Bakeyev. On Mon, Dec 4, 2017 at 5:46 PM, Peter Eriksson via samba < samba at lists.samba.org> wrote:> 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 > > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba >
On Mon, Dec 04, 2017 at 05:46:02PM +0100, Peter Eriksson via samba wrote:> Is it normal that the gencache.tdb should grow and grow “forever” and fill up with “RA/<hex>” posts?More than a year has passed -- 4.10 should fix this issue. Regards, Volker -- Besuchen Sie die verinice.XP 2019 in Berlin! Anwenderkonferenz für Informationssicherheit 26.-28. Februar 2019 - im Hotel Radisson Blu Info & Anmeldung hier: http://veriniceXP.org SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen phone: +49-551-370000-0, fax: +49-551-370000-9 AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen http://www.sernet.de, mailto:kontakt at sernet.de