Hi,
In short the server stops reading data from the connection until it gets working threads to process them. (So some operations get queued in the kernel TCP/IP buffers but quickly the server stops responding until it can process new operations) We sometimes see that behavior when a very long write operation occurs and all the other threads collide on the database txn locks.
The only thing that is queued is the fact that there is network activity on a connection. There is no explicit size limit to this queue.
But its size is always smaller than nsslapd-maxthreadsperconn * "max number of connections" (which is itself limited to 64K or by the number of available file descriptors)
So the important parameters are:
nsslapd-threadnumber that determines how many threads can process operation.
And nsslapd-maxthreadsperconn that determines how many concurrent operations may run on a single connection.
The process "nofile" hard limit (usually set in systemd config file)
Regards,
Pierre
In short the server stops reading data from the connection until it gets working threads to process them. (So some operations get queued in the kernel TCP/IP buffers but quickly the server stops responding until it can process new operations) We sometimes see that behavior when a very long write operation occurs and all the other threads collide on the database txn locks.
The only thing that is queued is the fact that there is network activity on a connection. There is no explicit size limit to this queue.
But its size is always smaller than nsslapd-maxthreadsperconn * "max number of connections" (which is itself limited to 64K or by the number of available file descriptors)
So the important parameters are:
nsslapd-threadnumber that determines how many threads can process operation.
And nsslapd-maxthreadsperconn that determines how many concurrent operations may run on a single connection.
The process "nofile" hard limit (usually set in systemd config file)
Regards,
Pierre
On Thu, Dec 14, 2023 at 1:40 AM Nyquist <dongminic@xxxxxxxxx> wrote:
If the LDAP server receives excessive requests, how do you handle the request information? I would like to inquire whether request information is stored sequentially in the queue, and if so, where can I manage the size and settings of the queue?
--
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
--
389 Directory Server Development Team
389 Directory Server Development Team
-- _______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
