Re: huge tlb support
| От | Robert Haas |
|---|---|
| Тема | Re: huge tlb support |
| Дата | |
| Msg-id | CA+TgmoZ+FvxyYi9DHbEBJ0CLPBdE7we-fOxv11qO=r3NxP+6Xg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: huge tlb support (Andres Freund <andres@2ndquadrant.com>) |
| Ответы |
Re: huge tlb support
|
| Список | pgsql-hackers |
On Tue, Aug 21, 2012 at 11:31 AM, Andres Freund <andres@2ndquadrant.com> wrote: > On Tuesday, August 21, 2012 05:30:28 PM Robert Haas wrote: >> On Thu, Aug 16, 2012 at 10:53 PM, David Gould <daveg@sonic.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. Hmm. I guess you're right. But why would it be different? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: