ns-slapd processes not dying

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 at 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 at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/389-users/attachments/20100828/c0cf46a6/attachment.html 


[Index of Archives]     [Fedora User Discussion]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Yosemite Photos]     [Linux Apps]     [Maemo Users]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux