| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | David Gould <daveg(at)sonic(dot)net> |
| Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, YAMAMOTO Takashi <yamt(at)mwd(dot)biglobe(dot)ne(dot)jp>, pgsql-hackers(at)postgresql(dot)org, josh(at)agliodbs(dot)com |
| Subject: | Re: huge tlb support |
| Date: | 2012-08-21 15:30:28 |
| Message-ID: | CA+TgmoapygJk+7TCLgZthYFDZZy8nCUDgFxOLwjmyHQGVnYKQQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Aug 16, 2012 at 10:53 PM, David Gould <daveg(at)sonic(dot)net> wrote:
> A warning, on RHEL 6.1 (2.6.32-131.4.1.el6.x86_64 #1 SMP) we have had
> horrible problems caused by transparent_hugepages running postgres on
> largish systems (128GB to 512GB memory, 32 cores). The system sometimes
> goes 99% system time and is very slow and unresponsive to the point of
> not successfully completing new tcp connections. Turning off
> transparent_hugepages fixes it.
Yikes! Any idea WHY that happens?
I'm inclined to think this torpedos any idea we might have of enabling
hugepages automatically whenever possible. I think we should just add
a GUC for this and call it good. If the state of the world improves
sufficiently in the future, we can adjust, but I think for right now
we should just do this in the simplest way possible and move on.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2012-08-21 15:31:27 | Re: huge tlb support |
| Previous Message | Amit Kapila | 2012-08-21 15:30:16 | Re: 9.2RC1 wraps this Thursday ... |