changing nsslapd-sizelimit in cn=config
by Rob Crittenden
In IPA I'm trying to set the value of nsslapd-sizelimit in cn=config
online using our LDAP tool. It is failing with LDAP error 16. What I'm
seeing is:
ipapython.ipaldap: DEBUG: update_entry modlist [(1, 'nsslapd-sizelimit',
[b'2000']), (0, 'nsslapd-sizelimit', [b'100000'])]
ldap.NO_SUCH_ATTRIBUTE: {'msgtype': 103, 'msgid': 16, 'result': 16,
'desc': 'No such attribute', 'ctrls': []
Basically I'm trying to delete the original value and adding a new one.
It seems like cn=config is being treated differently.
rob
2 years, 1 month
WARN - content-sync-plugin
by Orion Poplawski
I've started seeing these messages periodically after some update a while
back. Anything to be concerned about or should I just ignore them?
[29/Aug/2021:09:41:35.471107696 -0700] - WARN - content-sync-plugin -
sync_update_persist_betxn_pre_op - DB retried operation targets "cn=repl keep
alive 24,dc=nwra,dc=com" (op=0x7f32d57f8c00 idx_pl=0) => op not changed in PL
[29/Aug/2021:13:07:11.134986267 -0700] - WARN - content-sync-plugin -
sync_update_persist_betxn_pre_op - DB retried operation targets "cn=repl keep
alive 24,dc=nwra,dc=com" (op=0x7f32d5701400 idx_pl=0) => op not changed in PL
[29/Aug/2021:13:56:35.194828743 -0700] - WARN - content-sync-plugin -
sync_update_persist_betxn_pre_op - DB retried operation targets "cn=repl keep
alive 24,dc=nwra,dc=com" (op=0x7f32d56fe600 idx_pl=0) => op not changed in PL
[29/Aug/2021:15:37:11.119675538 -0700] - WARN - content-sync-plugin -
sync_update_persist_betxn_pre_op - DB retried operation targets
"dc=nwra,dc=com" (op=0x7f32d563cc00 idx_pl=0) => op not changed in PL
[29/Aug/2021:18:13:13.204063186 -0700] - WARN - content-sync-plugin -
sync_update_persist_betxn_pre_op - DB retried operation targets "cn=repl keep
alive 24,dc=nwra,dc=com" (op=0x7f32bcafbe00 idx_pl=0) => op not changed in PL
Thanks.
--
Orion Poplawski
IT Systems Manager 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 https://www.nwra.com/
2 years, 1 month
Re: Database and OS tuning. (open files)
by William Brown
> On 2 Sep 2021, at 00:50, Michael Starling <mlstarling31(a)hotmail.com> wrote:
>
> 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
There are also a number of IO tuning options for connection life inside LDAP you can tune to help discard and cycle out stale connections quicker.
https://access.redhat.com/documentation/en-us/red_hat_directory_server/11...
If we receive a partial message, how long to wait for the remaining components to be recieved.
https://access.redhat.com/documentation/en-us/red_hat_directory_server/11...
If a client is idle with no messages being received, how long before we disconnect them.
https://access.redhat.com/documentation/en-us/red_hat_directory_server/11...
Maximum number of connections. IIRC this might be automatically set from FD's in the system, but if not you may need to set this to probably 80% of your FD limit frlom the systemd service tunings you have provided.
Hope that helps,
--
Sincerely,
William Brown
Senior Software Engineer, Identity and Access Management
SUSE Labs, Australia
2 years, 1 month
Re: Database and OS tuning. (open files)
by Paul Robert Marino
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(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to 389-users-leave(a)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.fedoraproje...
> Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
2 years, 1 month
Database and OS tuning. (open files)
by Michael Starling
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
2 years, 1 month
