| Summary: | bind-dyndb-ldap reload takes too long with many zones | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Jatin Nansi <jnansi> |
| Component: | bind-dyndb-ldap | Assignee: | Petr Spacek <pspacek> |
| Status: | CLOSED WONTFIX | QA Contact: | Kaleem <ksiddiqu> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | 7.2 | CC: | pspacek, pvoborni |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-10-31 09:11:59 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
|
Description
Jatin Nansi
2016-10-04 08:04:27 UTC
It seems suspicious that the LDAP MOD operations take so long time. The very same scenario on a virtual machine with default IPA 4.4 installation and no LDAP server tunning took 9 seconds. I believe that this can be optimized even more with proper DS tunning. I was testing this with bind-dyndb-ldap-10.0-5.el7.x86_64 389-ds-base-1.3.5.10-11.el7.x86_64 (packages from RHEL 7.3). Having said that, I would start with LDAP server debugging/tunning. An alternative is to use log rotation built into BIND and avoid logrotate and thus avoid periodic reload. Please see: ftp://ftp.isc.org/isc/bind/cur/9.9/doc/arm/Bv9ARM.ch06.html#logging_grammar (channel - file - versions) Optimizing this in bind-dyndb-ldap would be a major change. Also, it is unclear what we should exactly change. "man rndc" defines reload command like this: > reload > Reload configuration file and zones. so some kind of work is inevitable. Let me know if I can help you somehow. I have recommended the customer to change named over to logging with syslog. This should alleviate the need to reload named when rotating logs. Steps are as follows:
~~~
1. An example configuration, based on the database-log channel configuration in your named.conf is as follows:
channel database-log {
syslog local1;
severity info;
print-category yes;
print-severity yes;
print-time no;
};
You should create similar channels for all categories (including default_debug) that you are already logging. You probably want to log all channels to the same syslog level (local1 in this case) - named will log the category of the message, so you will be able to identify the category of the message. The syslog daemon will timestamp the messages, so you don't need named to timestamp the message.
2. You should add the following configuration line to rsyslog.conf:
~~~
local1.* /var/log/named-syslog.log
~~~
3. You should add /var/log/named-syslog.log to the list of log files in the logrotate configuration file for syslog.
4. Delete the logrotate configuration file for named, so named is not restarted.
~~~
The customer is happy with the workaround of named logging to syslog and has closed the case. It probably isn't worth wasting any more engineering cycles on this bug, so should just close this bug? |