hi,
i had problems with "too many fds open" on some instances and after digging a bit i've found that ns-slapd dont die.
i got 5 similar installations and this is happening just in two of them and i can't identify what is about.
i've been recollecting process informations and i know for sure that the only process that keep increasing is ns-slapd and eventually, after some weeks, 389 starts refusing new connections and i got the "too many fds open" message.
i can increase max fds but the problem of processes keeping alive is still there.
anyone facing similar situation?
regards,
abosch
Hi,
You can try to change the following parameters to reduce the timeouts of the connections : * system parameters (reduce keepalive time to 700 seconds): echo "net.ipv4.tcp_keepalive_time = 700" >> /etc/sysctl.conf sysctl -p * 389 parameters in cn=config (change the maximum time limit per search operation to 120 sec & set idle connection timeout to 600 sec): nsslapd-timelimit: 120 nsslapd-idletimeout: 600
The file descriptor number used by a connecton can be seen in access log (fd=139) : [28/Aug/2010:14:35:08 +0200] conn=58377 fd=139 slot=139 SSL connection from x.x.x.x to x.x.x.x
You may also use /logconv.pl utility to see the long requests, number of parallel/oncurrent connections and file descriptor usage ('Highest FD taken') Total Connections: 2855 Peak Concurrent Connections: 4 Total Operations: 157116 Total Results: 157139 Overall Performance: 100.0% ... FDs Taken: 3112 FDs Returned: 3112 Highest FD Taken: 143 ... ----- Top 20 Most Frequent etimes -----
156965 etime=0 58 etime=1 58 etime=3 58 etime=2
@+
2010/8/27 Angel Bosch Mora angbosch@conselldemallorca.net
hi,
i had problems with "too many fds open" on some instances and after digging a bit i've found that ns-slapd dont die.
i got 5 similar installations and this is happening just in two of them and i can't identify what is about.
i've been recollecting process informations and i know for sure that the only process that keep increasing is ns-slapd and eventually, after some weeks, 389 starts refusing new connections and i got the "too many fds open" message.
i can increase max fds but the problem of processes keeping alive is still there.
anyone facing similar situation?
regards,
abosch
389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
Hi,
We had similar problem before, but I am not sure if it is related to your case.
The file descriptors that were opened by the ns-slapd process was all in a CLOSE_WAIT state. You can try execute "netstat -anput | grep CLOSE_WAIT" and see if there's a lot of dangling CLOSE_WAIT socket opened by ns-slapd.
If that was the case, I suggest you to update to the latest version of 389 directory because that has been fixed.
This is the bugzilla ticket that I submitted awhile back. https://bugzilla.redhat.com/show_bug.cgi?id=567429
- David
2010/8/28 Andrey Ivanov andrey.ivanov@polytechnique.fr
Hi,
You can try to change the following parameters to reduce the timeouts of the connections :
- system parameters (reduce keepalive time to 700 seconds): echo "net.ipv4.tcp_keepalive_time =
700" >> /etc/sysctl.conf sysctl -p
- 389 parameters in cn=config (change the maximum time limit per search
operation to 120 sec & set idle connection timeout to 600 sec): nsslapd-timelimit: 120 nsslapd-idletimeout: 600
The file descriptor number used by a connecton can be seen in access log (fd=139) : [28/Aug/2010:14:35:08 +0200] conn=58377 fd=139 slot=139 SSL connection from x.x.x.x to x.x.x.x
You may also use /logconv.pl utility to see the long requests, number of parallel/oncurrent connections and file descriptor usage ('Highest FD taken') Total Connections: 2855 Peak Concurrent Connections: 4 Total Operations: 157116 Total Results: 157139 Overall Performance: 100.0% ... FDs Taken: 3112 FDs Returned: 3112 Highest FD Taken: 143 ... ----- Top 20 Most Frequent etimes -----
156965 etime=0 58 etime=1 58 etime=3 58 etime=2
@+
2010/8/27 Angel Bosch Mora angbosch@conselldemallorca.net
hi,
i had problems with "too many fds open" on some instances and after digging a bit i've found that ns-slapd dont die.
i got 5 similar installations and this is happening just in two of them and i can't identify what is about.
i've been recollecting process informations and i know for sure that the only process that keep increasing is ns-slapd and eventually, after some weeks, 389 starts refusing new connections and i got the "too many fds open" message.
i can increase max fds but the problem of processes keeping alive is still there.
anyone facing similar situation?
regards,
abosch
389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
-- 389 users mailing list 389-users@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-users
----- Missatge original -----
Hi,
We had similar problem before, but I am not sure if it is related to your case.
The file descriptors that were opened by the ns-slapd process was all in a CLOSE_WAIT state. You can try execute "netstat -anput | grep CLOSE_WAIT" and see if there's a lot of dangling CLOSE_WAIT socket opened by ns-slapd.
seems that is not the case.
i can see lot of ESTABLISHED connections, but not a single CLOSE_WAIT. ex:
tcp 0 0 ::ffff:172.26.67.79:389 ::ffff:192.168.224.16:53143 ESTABLISHED 315/ns-slapd
the quick and dirty workaround is restarting the instance every night.
regards,
abosch
389-users@lists.fedoraproject.org
-
Angel Bosch Mora -
Chun Tat David Chu -
Ivanov Andrey (M.)