| From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, David Gould <daveg(at)sonic(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, YAMAMOTO Takashi <yamt(at)mwd(dot)biglobe(dot)ne(dot)jp>, josh(at)agliodbs(dot)com |
| Subject: | Re: huge tlb support |
| Date: | 2012-08-21 15:31:27 |
| Message-ID: | 201208211731.28298.andres@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tuesday, August 21, 2012 05:30:28 PM Robert Haas wrote:
> 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.
He is talking about transparent hugepages not hugepages afaics.
Andres
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2012-08-21 15:41:00 | Re: New statistics for WAL buffer dirty writes |
| Previous Message | Robert Haas | 2012-08-21 15:30:28 | Re: huge tlb support |