Re: postgresql.conf recommendations

Поиск
Список
Период
Сортировка
От Josh Krupka
Тема Re: postgresql.conf recommendations
Дата
Msg-id CAB6McgUr+JzKZ1v0==v=FQRqVsjwMviqeDLZQBixqC+3E8Bvog@mail.gmail.com
обсуждение исходный текст
Ответ на Re: postgresql.conf recommendations  (Johnny Tan <johnnydtan@gmail.com>)
Список 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 по дате отправления: