From owner-freebsd-questions@FreeBSD.ORG Fri Oct 10 10:37:57 2008 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7180910656A4 for ; Fri, 10 Oct 2008 10:37:57 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [76.96.62.48]) by mx1.freebsd.org (Postfix) with ESMTP id 08A5E8FC19 for ; Fri, 10 Oct 2008 10:37:56 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA01.westchester.pa.mail.comcast.net ([76.96.62.11]) by QMTA05.westchester.pa.mail.comcast.net with comcast id QyZF1a00N0EZKEL55ydvL7; Fri, 10 Oct 2008 10:37:55 +0000 Received: from koitsu.dyndns.org ([69.181.141.110]) by OMTA01.westchester.pa.mail.comcast.net with comcast id Qydu1a0012P6wsM3MyduK9; Fri, 10 Oct 2008 10:37:55 +0000 X-Authority-Analysis: v=1.0 c=1 a=ruLxGkQunecA:10 a=pauEDJqJWUQA:10 a=QycZ5dHgAAAA:8 a=sjL84REO6ocb_XtCm6oA:9 a=3x7T1Fso7O3TLsqDckIA:7 a=wx80ffymwAwD09_BzfSacvWSXJ8A:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id CD762C9419; Fri, 10 Oct 2008 03:37:53 -0700 (PDT) Date: Fri, 10 Oct 2008 03:37:53 -0700 From: Jeremy Chadwick To: Laszlo Nagy Message-ID: <20081010103753.GA30120@icarus.home.lan> References: <48EF14E1.9080808@shopzeus.com> <57200BF94E69E54880C9BB1AF714BBCB5DE18C@w2003s01.double-l.local> <48EF1C9C.3020201@shopzeus.com> <20081010091738.GA27925@icarus.home.lan> <48EF23CB.8020104@shopzeus.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48EF23CB.8020104@shopzeus.com> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: Berta =?iso-8859-1?Q?S=E1ndor?= , freebsd-questions@freebsd.org, Johan Hendriks Subject: Re: [SOLVED] Re: 7.1 hangs, shutdown terminated X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Oct 2008 10:37:57 -0000 On Fri, Oct 10, 2008 at 11:43:39AM +0200, Laszlo Nagy wrote: > >>>> If find / -sx is running and is consuming all CPU, what is the >>>> value of vfs.ufs.dirhash_mem: >>>> >>>> # sysctl -a | grep dirhash >>>> >>> shopzeus# sysctl -a | grep dirhash >>> vfs.ufs.dirhash_docheck: 0 >>> vfs.ufs.dirhash_mem: 2095818 >>> vfs.ufs.dirhash_maxmem: 2097152 >>> vfs.ufs.dirhash_minsize: 2560 >>> >>> >>>> Make sure vfs.ufs.dirhash_mem: is not close to vfs.ufs.dirhash_maxmem: >>>> >>> All right. It is close to it. Which one should I increase? I put this >>> into /etc/sysctl.conf: >>> >>> >>> vfs.ufs.dirhash_maxmem=8228608 >>> >>> Would it be scufficient? >>> >> >> We don't know, and can't tell you. You'll have to monitor >> vfs.ufs.dirhash_mem occasionally to see if you start to reach >> vfs.ufs.dirhash_maxmem. >> >> I have a tendency to use vfs.ufs.dirhash_maxmem=16777216, which is >> 16384*1024 (16MBytes). >> >> I'm not fully confident this is what's causing your problem, but it's >> definitely a recommendation by Johan. >> > Thank you very much! Probably you are right. Our users use shared IMAP > folders and sometimes they keep ten thousands of messages in one folder. > I have increased dirhash_maxmem to 64MB and see what happens. > > Unfortunately, I cannot play with the hardware because it is in a server > park, and it must be up 99.99% on workdays. > > I hope dirhash will solve the problem. I'm setting this to [SOLVED] and > come back if it happens again. (Maybe on monday?) > > By the way, there is nothing in /etc/periodic that would execute "find / > -sx". Can somebody explain what is this for, and why it was started by > root? Is it being used instead for enumerating files in a directory, > when dir hash is full? Firstly, I see a periodic(8) job that DOES use find -sx, which means your attempt to track it down was faulty, and your syntax should have been "find -sx /" not "find / -sx". See here: /etc/periodic/security/100.chksetuid: find -sx $MP /dev/null -type f \ $MP == mountpoint, e.g. /, /var, or any other mounted filesystem. So, what you saw was the periodic check looking for setuid-root binaries. Secondly, the kernel does not spawn userland processes like find(1). Thirdly, dirmem and dirmem_max are *pure* kernel things. What they do is control the amount of memory used for directory structure caching; rather than continually hit the disk every time and spend all that time handling directory contents, the kernel can cache previously-fetched contents in memory. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |