From: | Matthew <matthew(at)flymine(dot)org> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Strange behavior: pgbench and new Linux kernels |
Date: | 2008-04-17 15:52:06 |
Message-ID: | Pine.LNX.4.64.0804171538200.20402@aragorn.flymine.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Thu, 17 Apr 2008, Greg Smith wrote:
> So in the case of this simple benchmark, I see an enormous performance
> regression from the newest Linux kernel compared to a much older one. I need
> to do some version bisection to nail it down for sure, but my guess is it's
> the change to the Completely Fair Scheduler in 2.6.23 that's to blame.
That's a bit sad. From Documentation/sched-design-CFS.txt (2.6.23):
> There is only one
> central tunable (you have to switch on CONFIG_SCHED_DEBUG):
>
> /proc/sys/kernel/sched_granularity_ns
>
> which can be used to tune the scheduler from 'desktop' (low
> latencies) to 'server' (good batching) workloads. It defaults to a
> setting suitable for desktop workloads. SCHED_BATCH is handled by the
> CFS scheduler module too.
So it'd be worth compiling a kernel with CONFIG_SCHED_DEBUG switched on
and try increasing that value, and see if that fixes the problem.
Alternatively, use sched_setscheduler to set SCHED_BATCH, which should
increase the timeslice (a Linux-only option).
Matthew
--
Psychotics are consistently inconsistent. The essence of sanity is to
be inconsistently inconsistent.
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2008-04-17 16:12:31 | Re: SQL Function Slowness, 8.3.0 |
Previous Message | Gunther Mayer | 2008-04-17 15:42:05 | Re: Exact index overhead |