From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Francois Tigeot <ftigeot(at)wolfpond(dot)org> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SYSV shared memory vs mmap performance |
Date: | 2013-01-25 13:40:20 |
Message-ID: | 20130125134020.GT21914@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Sep 13, 2012 at 08:30:03AM +0200, Francois Tigeot wrote:
> Hi,
>
> Given the recent decision to switch from SYSV shared memory to mmap and
> the concerns which were made with regard to performance on *BSD kernels,
> I've run a few Pgbench tests on a spare Xeon box.
>
> I tested PostgreSQL-9.3 from June 28th, as of commits:
> - c5b3451a8e72cb7825933d4f4827f467cb38b498 (mmap)
> - 5d594b73d988b1ac78c49d8a84deae6bae876d01 (sysv shared memory)
>
> I also used both Scientific Linux-6.2 and DragonFly BSD-3.1; the results
> are in the attached PDF document.
>
> To cut a long story short, Linux doesn't show any difference and DragonFly
> sees some heavy degradation under load. After a while, it starts swapping
> and performance goes to hell.
>
> The only *BSD system tested was DragonFly but I know from previous pgbench
> tests FreeBSD and NetBSD follow a similar performance curve
>
> The famous kern.ipc.shm_use_phys sysctl was set to 1, which is the default
> setting.
Just a reminder we might have *BSD performance issues with our use of
Posix shared memory in Postgres 9.3. I am attaching the PDF the user
posted.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
Attachment | Content-Type | Size |
---|---|---|
Pg-benchmarks.2012-09.Sysv_shm.vs.mmap.pdf | application/pdf | 66.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2013-01-25 13:43:19 | Re: pgsql: Make pg_dump exclude unlogged table data on hot standby slaves |
Previous Message | Bruce Momjian | 2013-01-25 13:26:51 | Re: [BUGS] BUG #7515: DROP TABLE IF EXISTS fails if schema does not exist |