| From: | Adrien Nayrat <adrien(dot)nayrat(at)dalibo(dot)com> |
|---|---|
| To: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com> |
| Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Doc tweak for huge_pages? |
| Date: | 2017-12-04 08:48:44 |
| Message-ID: | 4cc3fb22-d187-86f5-3b52-a786894fc74f@dalibo.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 12/01/2017 05:35 AM, Thomas Munro wrote:
>> since it also
>> supports "transparent" hugepages.
> Hmm. Yeah, it does, but apparently it's not so transparent.
+1. We saw performance drop with transparent_hugepage enabled on server with
more than 256GB RAM. Access to the cache where slow down when kernel try to
defragment pages.
When that happens, we saw the function isolate_freepages_block appearing in most
consuming function with perf top.
Thanks to Marc Cousin analysis, putting "madvise" to
/sys/kernel/mm/transparent_hugepage/enabled solved the problem. He also notice
that THP only works for "anonymous memory mappings"[1] (shared_buffers are not
anonymous).
1: https://www.kernel.org/doc/Documentation/vm/transhuge.txt
Regards,
--
Adrien NAYRAT
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Huong Dangminh | 2017-12-04 09:26:00 | RE: Re: User defined data types in Logical Replication |
| Previous Message | Alexander Korotkov | 2017-12-04 08:29:44 | Re: [HACKERS] proposal: psql command \graw |