I would also tune the TCP heartbeat in sysctl to make it shorter rather than the idle timeout. the default is 2 hours and not to cut it off if heartbeats are missed. I prefer to make it 2 minutes and kill on the second missed heartbeat for LDAP servers. the reason for this is that there are a lot of sloppy LDAP clients out there that exit without closing their connections. btw heartbeats only happen when a TCP session is open and idle, they don't happen when there is active traffic. here is a howto that will explain more https://tldp.org/HOWTO/TCP-Keepalive-HOWTO/usingkeepalive.html Changing the TCP heartbeat settings on the server wont add any overhead because its already there in the kernel any way, also its a good way to filter out bad clients that left zombie connections open but won't break clients that are legitimately idle, but will reuse the connections later. Zombie connections are what usually cause LDAP servers to hit the max open file limit, not legitimately idle connections, so it's always a good place to start tuning your LDAP server.
On Wed, Sep 1, 2021 at 10:11 AM Michael Starling mlstarling31@hotmail.com wrote:
Hello.
I enabled chaining in our environment to replicate password policy attributes from the consumers and hubs back to the masters and now we are seeing these errors in the logs We have to reboot for the system to become stable again.
31/Aug/2021:23:31:36.584135966 -0400] - ERR - configure_pr_socket - Unable to move socket file descriptor 42 above 64: OS error 24 (Too many open files)
Is this behavior expected with this change?
Are there any other dirsrv tuning options that you think would be helpful?
Right now, I have made the following changes.
nsslapd-idletimeout: 600
I have bumped nofile for dirsrv from 8192 to 20000.
dirsrv - nofile 200000
We have also set open file limit in the service file for DS
[Service] LimitNOFILE=200000
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
________________________________ From: Paul Robert Marino prmarino1@gmail.com Sent: Wednesday, September 1, 2021 10:30 AM To: General discussion list for the 389 Directory server project. 389-users@lists.fedoraproject.org Subject: [389-users] Re: Database and OS tuning. (open files)
I would also tune the TCP heartbeat in sysctl to make it shorter rather than the idle timeout. the default is 2 hours and not to cut it off if heartbeats are missed. I prefer to make it 2 minutes and kill on the second missed heartbeat for LDAP servers. the reason for this is that there are a lot of sloppy LDAP clients out there that exit without closing their connections. btw heartbeats only happen when a TCP session is open and idle, they don't happen when there is active traffic. here is a howto that will explain more https://tldp.org/HOWTO/TCP-Keepalive-HOWTO/usingkeepalive.html Changing the TCP heartbeat settings on the server wont add any overhead because its already there in the kernel any way, also its a good way to filter out bad clients that left zombie connections open but won't break clients that are legitimately idle, but will reuse the connections later. Zombie connections are what usually cause LDAP servers to hit the max open file limit, not legitimately idle connections, so it's always a good place to start tuning your LDAP server.
Thank you, Paul.
This is our current setting. Looks like we are at 5 minutes so we should be ok.
net.ipv4.tcp_keepalive_intvl = 75 net.ipv4.tcp_keepalive_probes = 9 net.ipv4.tcp_keepalive_time = 300
On Wed, Sep 1, 2021 at 10:11 AM Michael Starling mlstarling31@hotmail.com wrote:
Hello.
I enabled chaining in our environment to replicate password policy attributes from the consumers and hubs back to the masters and now we are seeing these errors in the logs We have to reboot for the system to become stable again.
31/Aug/2021:23:31:36.584135966 -0400] - ERR - configure_pr_socket - Unable to move socket file descriptor 42 above 64: OS error 24 (Too many open files)
Is this behavior expected with this change?
Are there any other dirsrv tuning options that you think would be helpful?
Right now, I have made the following changes.
nsslapd-idletimeout: 600
I have bumped nofile for dirsrv from 8192 to 20000.
dirsrv - nofile 200000
We have also set open file limit in the service file for DS
[Service] LimitNOFILE=200000
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
_______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
389-users@lists.fedoraproject.org