Project

General

Profile

Actions

Bug #119

closed

(cache_lock diagnostics)

Added by dillon about 18 years ago. Updated over 17 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

Description

:This is a DFly 1.4.0 system (DragonFly 1.4.0-RELEASE (myhost) #3: Thu
:Jan 19 08:33:37 EST 2006) that is being used primarily as a spam
:filtering machine and, as such, sees some pretty high volume. About a
:week ago I started getting the following type of messages appearing in
:my logs and am wondering about a) the nature of the severity these
:represent b) the underlying cause and c) how to diagnose further.
:
:As a side note, this machine was upgraded from a 1.0 system and the
:ports replaced/upgraded using pkgsrc.

As long as the machine doesn't deadlock in the name resolution code,
the messages are harmless. The messages are printed when the filename
resolver blocks for more then one second and will occur more often on
busy systems.
I should probably change the default timeout.  You can adjust the
default timeout with the debug.nclockwarn sysctl. This value is in
ticks so 100 = 1 second. Try 500 (5 seconds). The sysctl only effects
the reporting of the warning.
-Matt
Actions #1

Updated by sven about 18 years ago

On Tue, 2006-03-21 at 10:08 -0800, Matthew Dillon wrote:

:This is a DFly 1.4.0 system (DragonFly 1.4.0-RELEASE (myhost) #3: Thu
:Jan 19 08:33:37 EST 2006) that is being used primarily as a spam
:filtering machine and, as such, sees some pretty high volume. About a
:week ago I started getting the following type of messages appearing in
:my logs and am wondering about a) the nature of the severity these
:represent b) the underlying cause and c) how to diagnose further.
:
:As a side note, this machine was upgraded from a 1.0 system and the
:ports replaced/upgraded using pkgsrc.

As long as the machine doesn't deadlock in the name resolution code,
the messages are harmless. The messages are printed when the filename
resolver blocks for more then one second and will occur more often on
busy systems.

I should probably change the default timeout. You can adjust the
default timeout with the debug.nclockwarn sysctl. This value is in
ticks so 100 = 1 second. Try 500 (5 seconds). The sysctl only effects
the reporting of the warning.

-Matt

Sounds good, I will use the sysctl then to keep the chatter down :-) As
far as I can tell, the box still performs as usual and I haven't seen
any specific performance issues resulting from this.

Thanks

Sven

p.s. Sorry about the lack of subject line; when I originally posted this
I pasted the errors into the body and forgot to go back and add a
subject line.

Actions

Also available in: Atom PDF