Bug #119

(cache_lock diagnostics)

Added by dillon almost 9 years ago. Updated about 8 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

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

History

#1 Updated by sven almost 9 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.

Also available in: Atom PDF