Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
When we start process named-chroot memory consumption is normal. When we are using command rndc reload in order to reload configuration, the memory is increased twice and consume high memory (90%) and impacts server reactivity.
Version-Release number of selected component (if applicable):
This behaviour is experiencing on RHEL 7.6 since bind version 9.9.4.61.
How reproducible:
each time we execute rndc reload.
It seems appear since this version package (9.9.4.61) was build with option --with-tuning=large. ISC documentation says "Note also, that running a binary that has been built with --with-tuning=large may not help the performance of a smaller and low-end BIND server because it will cause named to consume more resources than it needs, which in itself could cause issues rather than improving throughput." We are in this case, it impacts server performance as memory is not free.
Could you provide us built packages without option --with-tuning=large?
I confirm there is some raise in used memory after rndc reload, both in named-chroot and named service. But it increases only the first time server is reloaded, after that is keeps at the same levels.
But there are absolutly no numbers I can work with in this report.
Prepared just few data entries by this command:
yum install ldns
ldns-gen-zone -a 10000 -o test named.empty > /var/named/test.zone
cat NAMEDCONF >> /etc/named.conf
zone "test" IN {
type master;
file "test.zone";
};
NAMEDCONF
I used this command to test it:
$ systemctl start named-chroot && ps u -C named && rndc reload && ps u -C named
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
named 23948 0.2 4.5 233428 85144 ? Ssl 06:38 0:00 /usr/sbin/named
server reload successful
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
named 23948 0.3 7.9 299744 150388 ? Ssl 06:38 0:00 /usr/sbin/named
I can see significant increase in used RSS memory. But it is far from 90% as reported.
No configuration or number of zones or data were provided. No output of rndc stats is available, which should be relevant. Can it be run before reload and after it? Then contents of last parts in /var/named/data/named_stats.txt should contain some changed data.
I can search why it increases memory usage. Is customer limiting cache size by max-cache-size option to any value? How many zones and records does customer have in their configuration?
This reported issue is the same as older bug #1578051. Even outcome seems the same, it became issue with --tuning=large. Would be solved as single bug eventually.
*** This bug has been marked as a duplicate of bug 1578051 ***