From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: spinlocks on HP-UX |
Date: | 2011-08-30 20:53:30 |
Message-ID: | CA+TgmoZjSEEgHBbekF4Rp=E=SkX5QSmOtQE924csOwAS-F_VDg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Aug 30, 2011 at 4:37 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> If this is on Linux, I am surprised
>> that you didn't get killed by the lseek() contention problem on a
>> machine with that many cores.
>
> Hm ... now that you mention it, all of these tests have been using
> the latest-and-greatest unreleased RHEL kernels. Maybe Red Hat already
> fixed that contention problem in their kernel? Have you got a RH
> bugzilla number for the issue?
No, I haven't had much luck filing bugs against Red Hat releases, so
I've sort of given up on that. I did have some off-list
correspondence with a Red Hat engineer who red my blog post, though.
It should be pretty easy to figure it out, though. Just fire up
pgbench with lots of clients (say, 160) and run vmstat in another
window. If the machine reports 10% system time, it's fixed. If it
reports 90% system time, it's not.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Jaime Casanova | 2011-08-30 21:33:55 | Re: Comparing two PostgreSQL databases -- order of pg_dump output |
Previous Message | Tom Lane | 2011-08-30 20:44:11 | Re: pg_upgrade automatic testing |