Re: postgresql.conf recommendations - Mailing list pgsql-performance

From Josh Krupka
Subject Re: postgresql.conf recommendations
Date
Msg-id CAB6McgUr+JzKZ1v0==v=FQRqVsjwMviqeDLZQBixqC+3E8Bvog@mail.gmail.com
Whole thread Raw
In response to Re: postgresql.conf recommendations  (Johnny Tan <johnnydtan@gmail.com>)
List pgsql-performance
I originally got started down that trail because running perf top while having some of the slow query issues showed compaction_alloc at the top of the list.  That function is the THP page compaction which lead me to some pages like:
http://www.olivierdoucet.info/blog/2012/05/19/debugging-a-mysql-stall/
http://structureddata.org/2012/06/18/linux-6-transparent-huge-pages-and-hadoop-workloads/
https://gist.github.com/fgbreel/4454559
Only the last is around pg, but I think they all may still be applicable.

 The kernel docs in Documentation/vm/transhuge.txt have an explanation of the metrics

We hadn't been having the issue that much until a few weeks ago, when we started using the rest of our free memory for page cache.. my thoughts were if we have no more memory that's totally free, it might be doing compaction more.  That lead me to find how often compaction is happening, but like I said I don't know how to tell how *long* it's happening - someone who knows systemtap better than I might be able to help with the collection of that info assuming the right systemtap events are there.

One thing to keep in mind is the page you linked to (http://www.pythian.com/blog/performance-tuning-hugepages-in-linux/) talks mostly about *regular* large pages, which are related but different than THP.

I have yet to be able to prove THP's involvement one way or the other, but we are going to try some things on a test box to zero in on it. 

pgsql-performance by date:

Previous
From: Jeff Janes
Date:
Subject: Re: postgresql.conf recommendations
Next
From: Kevin Grittner
Date:
Subject: Re: postgresql.conf recommendations