Re: how to (temporarily) disable/minimize benefits of disk block cache or postgresql shared buffer

Dear Criag,

Thanks for thinking about it.I do not understand why u feel OpenVz is weird.
at the most its not very popular. But lets not get into that debate as its
not
the proper forum. From your reply i understand that there is not a easy and
clean way of doing it. Since performance related profiling requires multiple
iterations it is not feasible to reboot the machine. I think i will try to
profile
my code using new and unique input parameters in each iteration, this shall
roughly serve my purpose.

On Fri, Jul 2, 2010 at 8:30 AM, Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>wrote:

> 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/
>