From: Craig Ringer <craig@postnewspapers.com.au>
To: Rajesh Kumar Mallah <mallah.rajesh@gmail.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: how to (temporarily) disable/minimize benefits of disk block cache or postgresql shared buffer
Date: Fri, 02 Jul 2010 11:00:51 +0800
Message-ID: <4C2D5663.4070100@postnewspapers.com.au> (raw)
In-Reply-To: <AANLkTinFYSv9zxvDvKi9ChHtPkGh-KkdNbzU56tbOBY8@mail.gmail.com>
References: <AANLkTin0eIqjfIF2KoUcclnH_86X6aqOh5yNygu6f4pf@mail.gmail.com>
<4C2CC45F.4060505@postnewspapers.com.au>
<AANLkTinFYSv9zxvDvKi9ChHtPkGh-KkdNbzU56tbOBY8@mail.gmail.com>
On 02/07/10 01:59, Rajesh Kumar Mallah wrote:
> I had set it to 128kb
> it does not really work , i even tried your next suggestion. I am in
> virtualized
> environment particularly OpenVz. where echo 3 > /proc/sys/vm/drop_caches
> does not work inside the virtual container, i did it in the hardware node
> but still does not give desired result.
Yeah, if you're in a weird virtualized environment like that you're
likely to have problems, because caching can be done at multiple levels.
In the case of OpenVZ, it's hard to know what the "guest" and what the
"host" even is sometimes, and I wouldn't trust it to respect things like
the Linux VM cache management.
You might have to fall back on the classic method: a program that tries
to allocate as much RAM as it can. On Linux this is EXTREMELY unsafe
unless you ensure you have vm overcommit disabled (see the postgresql
docs) because by default Linux systems will never fail a memory
allocation - instead they'll go looking for a big process to kill to
free some memory. In theory this should be your memory gobbler program,
but in reality the OOM killer isn't so predictable.
So: try turning vm overcommit off, then writing (or finding) a simple
program that keeps on malloc()ing memory until an allocation call fails.
That should force any caches out, freeing you for another cold run.
Note that this method won't just force out the obvious caches like
postgresql data files. It also forces out things like caches of running
binaries. Things will grind to an absolute crawl for a minute or two
before resuming normal speed, because *everything* has to come back from
disk at once. The same is true of using /proc/sys/vm/drop_caches to drop
all caches.
I guess, in the end, nothing really subtitutes for a good reboot.
--
Craig Ringer
Tech-related writing: http://soapyfrogs.blogspot.com/
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: craig@postnewspapers.com.au, mallah.rajesh@gmail.com
Subject: Re: how to (temporarily) disable/minimize benefits of disk block cache or postgresql shared buffer
In-Reply-To: <4C2D5663.4070100@postnewspapers.com.au>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox