linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Chris Snook <csnook@redhat.com>
To: mike <mike503@gmail.com>
Cc: Dave Kleikamp <shaggy@linux.vnet.ibm.com>, linux-mm@kvack.org
Subject: Re: Drop caches - is this safe behavior?
Date: Fri, 24 Aug 2007 15:30:19 -0400	[thread overview]
Message-ID: <46CF31CB.10208@redhat.com> (raw)
In-Reply-To: <bd9320b30708240012m6d44ea6wb346d0b4db76e00d@mail.gmail.com>

mike wrote:
> On 8/23/07, Chris Snook <csnook@redhat.com> wrote:
>> I think the caches you had in mind were the ones that would be dropped
>> by echoing '1' into /proc/sys/vm/drop_caches, not the ones that would be
>> dropped by echoing '2' into it.  If you were dropping pagecache every
>> five minutes, it would kill your performance as you described.  As for
>> the question of safety, '3' should also be safe, but terrible for
>> performance, as it does all the harm of '1', plus some.
> 
> actually right now the performance seems to be good - using "2"

That's because you're not actually dropping that much.

> i'm willing to try "1" as well, as well as try the cache pressure one.
> i don't really know what caches i am clearing, but it seems that i get
> bottlenecked by something. restarting my webserver/php engines usually
> clears it up, so it seems like it is a buildup of something - and it
> always seems to be when memory is tight...

'1' drops pagecache, which is the kernel's cache of file data.  This is what you 
see under "cached" in the output of free.  '2' drops VFS cache, which is the 
kernel's cache of file *metadata*.  All of this appears under "used" in the 
output of free.  '3' drops both.  I think what you actually want is '1' or '3', 
though I assure you it would hurt performance considerably if you do either of 
those.

Turning up vm.vfs_cache_pressure instead of echoing '2' into drop_caches will 
cause the system to automatically free up more of that cache, but only when 
necessary.  It's much less disruptive to the system.

>> I'm not familiar with the "atsar" implementation, but it appears to be
>> an alternate implementation of the same thing.  It's an excellent tool
>> for long-term workload profiling.
> 
> actually, this might be a better method - is there any way to view the
> contents of the cache? or figure out what exactly is sitting in
> there/why my machine thinks it needs to cache 2 gigs of files so
> quickly?

If your system is caching 2 GB of files, that's because it's actually using 2 GB 
of files.  It *might* be useful to do a drop_caches *once* after the system 
boots and services start to clear out anything that's only used at boot, but 
doing this during normal operation is just shooting yourself in the foot.

Also, check out how your applications are using temporary files.  If files are 
deleted and aren't in use by any other processes, their pagecache gets dropped. 
  If your apps are being lazy and waiting for tmpwatch to clean up their 
garbage, it's sitting around in pagecache because nobody has informed the kernel 
that they're no longer needed.

	-- Chris

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

      reply	other threads:[~2007-08-24 19:30 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <bd9320b30708231645x3c6524efi55dd2cf7b1a9ba51@mail.gmail.com>
2007-08-24  0:07 ` mike
2007-08-24  1:36   ` Chris Snook
2007-08-24  4:35     ` mike
2007-08-24  5:14       ` Chris Snook
2007-08-24  4:47     ` Dave Kleikamp
2007-08-24  5:17       ` Chris Snook
2007-08-24  5:27         ` mike
2007-08-24  5:52           ` Chris Snook
2007-08-24  7:12             ` mike
2007-08-24 19:30               ` Chris Snook [this message]

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=46CF31CB.10208@redhat.com \
    --to=csnook@redhat.com \
    --cc=linux-mm@kvack.org \
    --cc=mike503@gmail.com \
    --cc=shaggy@linux.vnet.ibm.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