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>
prev parent 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