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.
.Directory Server now calculates the `dtablesize` based on the maximum number of opened descriptors
Previously, an administrator could set the connection table size manually by using the `nsslapd-conntablesize` configuration parameter. Consequently, when the connection table size was set too low, it affected the number of connections the server was able to support. With this update, Directory Server now calculates the size of the connection table dynamically effectively resolving the issue with too small connection table size. In addition, you no longer need to manually change the connection table size.
Description of problem:
It looks like dtablesize is being set to the maxfiledescriptors soft limit.
This problem was found while migrating from RHEL 7 IDM to RHEL 8 IDM at large client site. I came up at first with systemd override for maxfiledescriptors with value 65535 that resolved issues at client site. Though after further investigation was able to see the issue was not the value of the maxfiledescriptors. But that dtablesize was being set to the soft limit.
Version-Release number of selected component (if applicable):
Affects both RHEL 8 & RHEL 9.
How reproducible:
It looks like dtablesize is being set to the maxfiledescriptors soft limit.
Problem:
=======
389ds is not setting dtablesize properly based when systemd is setting the maxfiledescriptors with it's default settings.
dtablesize stays 1024 which causes massive slowdown once you hit around 950 connection. Basically queries are very slow. Also can't
go above around ~970 concurrent connections.
It looks like dtablesize is being set to the soft limit when it needs to be set to the actual limit.
So with no changes settings you see running commands:
systemctl show dirsrv@<INSTANCE> |grep -i Limitnofile
-----------------------------------------------------------------------------
- RHEL 8 (Directory Server)
LimitNOFILE=262144
LimitNOFILESoft=1024 < ---- Notice
- RHEL 9 (IDM system)
LimitNOFILE=524288
LimitNOFILESoft=1024 <--- Notice
dsconf <instance> config get nsslapd-maxdescriptors
--------------------------------------------------------------------------
- RHEL 8
nsslapd-maxdescriptors: 262144
- RHEL 9
nsslapd-maxdescriptors: 524288
-
(THE PROBLEM) dsconf <instance> monitor server |grep dtablesize
--------------------------------------------------------------------
- RHEL 8
dtablesize: 1024
- RHEL 9
dtablesize: 1024
WorkAround:
==========
Once in place connections can go very very high. Testing showed 7,000+ at client site. Also queries very fast.
Looks like this works because the override sets both hard and soft limit. So dtablesize gets a properly.
Workaround
-----------------
- RHEL 8
mkdir -p /etc/systemd/system/dirsrv@.service.d/
cat > /etc/systemd/system/dirsrv@.service.d/filelimts.conf << EOF
[Service]
LimitNOFILE=262144
EOF
systemctl daemon-reload
systemctl restart dirsrv@<instance>
- RHEL 9
mkdir -p /etc/systemd/system/dirsrv@.service.d/
cat > /etc/systemd/system/dirsrv@.service.d/filelimts.conf << EOF
[Service]
LimitNOFILE=524288
EOF
systemctl daemon-reload
systemctl restart dirsrv@<instance>
systemctl show dirsrv@<INSTANCE> |grep -i Limitnofile
-----------------------------------------------------------------------------
- RHEL 8 (Directory Server)
LimitNOFILE=262144
LimitNOFILESoft=262144 <---- THIS !!
- RHEL 9 (IDM system)
LimitNOFILE=524288
LimitNOFILESoft=524288 <-- THIS !!
dsconf <instance> config get nsslapd-maxdescriptors
--------------------------------------------------------------------------
- RHEL 8
nsslapd-maxdescriptors: 262144
- RHEL 9
nsslapd-maxdescriptors: 524288
dsconf <instance> monitor server |grep dtablesize
--------------------------------------------------------------------
- RHEL 8
dtablesize: 262144
- RHEL 9
dtablesize: 524288
Possible FIX
==========
Looks like the fix would be to have dtablesize set to maxfiledescriptors or the hard maxfiledescriptor limit.
@Marc
Upstream has already confirmed this as a bug and are working on it now.
dtablesize is in RHDS-12 I show it in the example.
The workaround provided is being used and has been proven by customers.
Hello,
For the customer tam would like to know what this test verified?
" I saw that the latest private message Bug 2210491 can you help understand what "automated test passed" means?
Thanks
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (389-ds:1.4 bug fix and enhancement update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2023:6965
Issue is resolved in RHEL 8.8 & 9.3 for IDM installs.
The issue is still there for RHDS installs as it looks like it installs an older version of 389-ds-base packages that do not contain the fix.
Description of problem: It looks like dtablesize is being set to the maxfiledescriptors soft limit. This problem was found while migrating from RHEL 7 IDM to RHEL 8 IDM at large client site. I came up at first with systemd override for maxfiledescriptors with value 65535 that resolved issues at client site. Though after further investigation was able to see the issue was not the value of the maxfiledescriptors. But that dtablesize was being set to the soft limit. Version-Release number of selected component (if applicable): Affects both RHEL 8 & RHEL 9. How reproducible: It looks like dtablesize is being set to the maxfiledescriptors soft limit. Problem: ======= 389ds is not setting dtablesize properly based when systemd is setting the maxfiledescriptors with it's default settings. dtablesize stays 1024 which causes massive slowdown once you hit around 950 connection. Basically queries are very slow. Also can't go above around ~970 concurrent connections. It looks like dtablesize is being set to the soft limit when it needs to be set to the actual limit. So with no changes settings you see running commands: systemctl show dirsrv@<INSTANCE> |grep -i Limitnofile ----------------------------------------------------------------------------- - RHEL 8 (Directory Server) LimitNOFILE=262144 LimitNOFILESoft=1024 < ---- Notice - RHEL 9 (IDM system) LimitNOFILE=524288 LimitNOFILESoft=1024 <--- Notice dsconf <instance> config get nsslapd-maxdescriptors -------------------------------------------------------------------------- - RHEL 8 nsslapd-maxdescriptors: 262144 - RHEL 9 nsslapd-maxdescriptors: 524288 - (THE PROBLEM) dsconf <instance> monitor server |grep dtablesize -------------------------------------------------------------------- - RHEL 8 dtablesize: 1024 - RHEL 9 dtablesize: 1024 WorkAround: ========== Once in place connections can go very very high. Testing showed 7,000+ at client site. Also queries very fast. Looks like this works because the override sets both hard and soft limit. So dtablesize gets a properly. Workaround ----------------- - RHEL 8 mkdir -p /etc/systemd/system/dirsrv@.service.d/ cat > /etc/systemd/system/dirsrv@.service.d/filelimts.conf << EOF [Service] LimitNOFILE=262144 EOF systemctl daemon-reload systemctl restart dirsrv@<instance> - RHEL 9 mkdir -p /etc/systemd/system/dirsrv@.service.d/ cat > /etc/systemd/system/dirsrv@.service.d/filelimts.conf << EOF [Service] LimitNOFILE=524288 EOF systemctl daemon-reload systemctl restart dirsrv@<instance> systemctl show dirsrv@<INSTANCE> |grep -i Limitnofile ----------------------------------------------------------------------------- - RHEL 8 (Directory Server) LimitNOFILE=262144 LimitNOFILESoft=262144 <---- THIS !! - RHEL 9 (IDM system) LimitNOFILE=524288 LimitNOFILESoft=524288 <-- THIS !! dsconf <instance> config get nsslapd-maxdescriptors -------------------------------------------------------------------------- - RHEL 8 nsslapd-maxdescriptors: 262144 - RHEL 9 nsslapd-maxdescriptors: 524288 dsconf <instance> monitor server |grep dtablesize -------------------------------------------------------------------- - RHEL 8 dtablesize: 262144 - RHEL 9 dtablesize: 524288 Possible FIX ========== Looks like the fix would be to have dtablesize set to maxfiledescriptors or the hard maxfiledescriptor limit.