From: | Rajesh Kumar Mallah <mallah(dot)rajesh(at)gmail(dot)com> |
---|---|
To: | Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: how to (temporarily) disable/minimize benefits of disk block cache or postgresql shared buffer |
Date: | 2010-07-02 19:22:33 |
Message-ID: | AANLkTikGhiN3aeWfF3EVlLu_WHFtAzQgZp1c9lhZYUQ_@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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/
>
From | Date | Subject | |
---|---|---|---|
Next Message | Rajesh Kumar Mallah | 2010-07-02 19:53:03 | Re: Extremely high CPU usage when building tables |
Previous Message | Deborah Fuentes | 2010-07-02 19:07:58 | Re: Extremely high CPU usage when building tables |