[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Repost: "Deferring operation" messages, slow operation?
On Wed, Nov 12, 2003 at 10:49:47AM -0700, Darren Gamble wrote:
> I have tried to increase the logging level as you have suggested, although
> without the slightest clue about what might be causing this, I am not sure
> what log levels to select. Some of the log levels cause our testing queries
> to time out, just due to the logging.
If your slapd server has extremely poor performance - particularly if
individual queries have a long latency with very low CPU use - I would
suspect DNS name resolution problems. You may find that more logging
makes it worse if the logs are set to include hostnames.
Use the 'host' command (or dig -x) to see how long it takes to resolve
IP addresses on your network into names. Check also for names
resolving to addresses - both fully qualified domain names and
short-form names. Also check these:
127.0.0.1
localhost
localhost.
localhost.localdomain
Any lookups that take more than 0.1s need investigating.
> I've included a section of the log at loglevel "1". While I can easily
> follow the "normal" log for connections and queries, this is more or less
> Greek to me. The original "deferring operation" messages don't appear at
> this level, just these "deferring conn" messages- I presume because they're
> not included at that level.
Log levels are additive (they are each a power of 2) I find 768
(512+256) to be a good start, with 769 to add more debugging info.
> "truss" is Solaris specific, I believe. There's probably something similar
> on Linux, although I am not sure if the information that I would get would
> mean anything to me.
Linux has strace to trace system calls and ltrace to trace library
calls. You don't need to understand everything that comes out of them
though - you are looking for things that take silly amounts of time,
and just reading the call parameters might be enough to give you a
clue.
> Also, do these "failed" messages mean anything to anyone else, or are they
> not related?
Not sure about the failed ber_get_next calls, but I am fairly sure the
'deferring' ones are benign.
Andrew
--
-----------------------------------------------------------------------
| From Andrew Findlay, Skills 1st Ltd |
| Consultant in large-scale systems, networks, and directory services |
| http://www.skills-1st.co.uk/ +44 1628 782565 |
-----------------------------------------------------------------------