[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:

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

> 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.

|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                +44 1628 782565     |