Richard Hesse wrote:
Thanks Richard, I¹ll give connection management a whirl.
What is the application which is generating this load?
Here¹s the log parser output (nice util btw):
----------- Access Log Output ------------
Restarts: 0
Total Connections: 4820
Peak Concurrent Connections: 19
Total Operations: 18017
Total Results: 18129
Overall Performance: 100.0%
Searches: 9960
Modifications: 6
Adds: 0
Deletes: 0
Mod RDNs: 0
Persistent Searches: 0
Internal Operations: 0
Entry Operations: 0
Extended Operations: 3224
Abandoned Requests: 0
Smart Referrals Received: 0
VLV Operations: 0
VLV Unindexed Searches: 0
SORT Operations: 0
SSL Connections: 1613
Entire Search Base Queries: 820
Unindexed Searches: 0
FDs Taken: 4828
FDs Returned: 4817
Highest FD Taken: 109
Broken Pipes: 0
Connections Reset By Peer: 0
Resource Unavailable: 17
- 17 (T1) Idle Timeout Exceeded
Binds: 4827
Unbinds: 65
LDAP v2 Binds: 0
LDAP v3 Binds: 4827
SSL Client Binds: 0
Failed SSL Client Binds: 0
SASL Binds: 0
Directory Manager Binds: 0
Anonymous Binds: 4813
Other Binds: 14
On 2/15/08 12:23 PM, "Rich Megginson" <rmeggins(a)redhat.com> wrote:
> Richard Hesse wrote:
>
>> Eh sorry about this but it appears that my original hunch was correct.
>> The 1.1 DS instance did indeed hang again recently. I was able to
>> check a localhost query and that failed, too. So the problem
>> definitely appears to be a hang in the FDS code somewhere. The
>> question is, how do I go about debugging this? Strace doesn¹t show
>> much at all. Enabling debug trace logging kills the server. Any ideas?
>> Thanks.
>>
> What sort of application(s) are you using to generate a load against the
> directory server?
>
> What does logconv.pl /var/log/dirsrv/slapd-instance/access say?
>
> If TRACE level logging is too expensive, you might try 8 Connection
> management
>
http://directory.fedoraproject.org/wiki/FAQ#Troubleshooting
>
>
>
--
Fedora-directory-users mailing list
Fedora-directory-users(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-directory-users