linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Howells <dhowells@redhat.com>
To: Mark Moseley <moseleymark@gmail.com>
Cc: dhowells@redhat.com,
	Linux filesystem caching discussion list 
	<linux-cachefs@redhat.com>,
	linux-kernel@vger.kernel.org
Subject: Re: [Linux-cachefs] 3.0.3 64-bit Crash running fscache/cachefilesd
Date: Thu, 20 Oct 2011 10:03:04 +0100	[thread overview]
Message-ID: <29711.1319101384@redhat.com> (raw)
In-Reply-To: <CAOH1cH=smX1tWLB6PwaRfcrOu5YErF3TGUDoRnLZGmxvGH9rAA@mail.gmail.com>

Mark Moseley <moseleymark@gmail.com> wrote:

> Out of curiosity, did the dump of /proc/fs/fscache/stats show anything
> interesting?

Ah...  I missed the attachment.

Looking at the number of pages currently marked (the difference between the
following two numbers):

	Pages  : mrk=3438716 unc=3223887
	...
	Pages  : mrk=7660986 unc=7608076
	Pages  : mrk=7668510 unc=7618591

That isn't very high.  214829 at the beginning, dropping to 49919 at the end.
I suspect this means that a lot of NFS inodes now exist that aren't now cached
(the cache is under no requirement to actually cache anything if it feels it
lacks the resources just to prevent the system from grinding to a halt).

Was the last item in the list just before a crash?  I presume not from your
comments.

> One slightly interesting thing, unrelated to fscache: This box is a
> part of a pool of servers, serving the same web workloads. Another box
> in this same pool is running 3.0.4, up for about 23 days (vs 6 hrs),
> and the nfs_inode_cache is approximately 1/4 of the 3.1.0-rc8's,
> size-wise, 1/3 #ofobjects-wise; likewise dentry in a 3.0.4 box with a
> much longer uptime is about 1/9 the size (200k objs vs 1.8mil objects,
> 45megs vs 400megs) as the 3.1.0-rc8 box. Dunno if that's the result of
> VM improvements or a symptom of something leaking :)

It also depends on what the load consists of.  For instance someone running a
lot of find commands would cause the server to skew in favour of inodes over
data, but someone reading/writing big files would skew it the other way.

Do I take it the 3.0.4 box is not running fscache, but the 3.1.0-rc8 box is?

David


  parent reply	other threads:[~2011-10-20  9:04 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-25 16:44 3.0.3 64-bit Crash running fscache/cachefilesd Mark Moseley
2011-08-26 12:52 ` [Linux-cachefs] " Дмитрий Ильин
2011-09-01 13:04 ` David Howells
2011-09-22 17:03   ` Mark Moseley
2011-09-22 21:41     ` Mark Moseley
2011-09-26 11:32     ` David Howells
2011-09-26 21:02       ` Mark Moseley
2011-09-27  0:59         ` Mark Moseley
2011-09-27 23:46           ` Mark Moseley
2011-09-29 14:57         ` David Howells
2011-09-29 15:51           ` Mark Moseley
2011-09-29 16:30           ` David Howells
2011-09-29 19:02             ` Mark Moseley
2011-09-29 22:11               ` Mark Moseley
2011-09-29 22:44                 ` Mark Moseley
2011-09-29 22:44               ` David Howells
2011-09-29 22:51                 ` Mark Moseley
2011-09-30 12:28                 ` David Howells
2011-09-30 18:57                   ` Mark Moseley
2011-09-30 20:10                   ` David Howells
2011-10-05 13:37                   ` David Howells
2011-10-05 13:49                   ` David Howells
2011-10-07 10:42                   ` David Howells
2011-10-08 16:32                     ` Mark Moseley
2011-10-11 13:07                     ` David Howells
2011-10-11 16:27                       ` Mark Moseley
2011-10-12  9:26                       ` David Howells
2011-10-12 10:05                       ` David Howells
2011-10-12 18:10                         ` Mark Moseley
2011-10-12 23:38                           ` Mark Moseley
2011-10-13 15:21                           ` David Howells
2011-10-13 20:48                             ` Mark Moseley
2011-10-14  9:22                             ` David Howells
2011-10-14 23:25                               ` Mark Moseley
2011-10-17 10:39                               ` David Howells
2011-10-19 12:25                               ` David Howells
2011-10-19 23:15                                 ` Mark Moseley
2011-10-20  8:46                                 ` David Howells
2011-10-20 19:37                                   ` Mark Moseley
2011-10-20  9:03                                 ` David Howells [this message]
2011-10-20 19:29                                   ` Mark Moseley
2011-10-20 23:05                                   ` David Howells
2011-10-21  0:21                                     ` Mark Moseley
2011-10-21  8:16                                     ` David Howells
2011-10-21 18:09                                       ` Mark Moseley
2011-12-13  1:56                                         ` Mark Moseley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=29711.1319101384@redhat.com \
    --to=dhowells@redhat.com \
    --cc=linux-cachefs@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=moseleymark@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).