[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: SLAPD_LISTEN increase
I agree that increasing both of those parameters is a good idea, but
as it says in the tunable docs
(http://docs.sun.com/app/docs/doc/806-6779/6jfmsfr8a?a=view#chapter4-53
- I'm running solaris 8) the actual ability of the application to
utilize the system is based on the listen() queue, so my basic
question is:
Why does openldap set this statically to 10? I know my hardware can
handle a lot more. If there isn't a good reason for it, should I feel
safe increasing it to better utilize my hardware and service more
connections? From what some basic benchmarking shows, it is pretty
safe to increase this number to a large one and rely on the system's
tunables to control the queues. However, if I wanted to limit the
application to, say, 65% of the system's available resources, I could
do so by setting SLAPD_LISTEN =
(.65*tcp_conn_req_max_q0*tcp_conn_req_max_q/total memory) or something
like that?
Or..
Would SLAPD_LISTEN not matter because the
tcp_conn_req_max_q0/tcp_conn_req_max_q would allow those 10 listen()'s
to -actually- handle many more connections and I should look to tune
them exclusively and leave the SLAPD_LISTEN alone?
Although it still feels like it is setting an arbitrary hard limit on
max listen()'s, even if those listens can (after tuning) handle more
transactions.
Maybe a thread count (ps -efL) and lsof of slapd would give a better
idea of how these parameters really affect the daemon.
>
> tcp_conn_req_max_q0 to 10240 may help resolve issues, along with
> increasing
> tcp_conn_req_max_q
>
> --Quanah