On Tue, 31 Mar 2009, Kevin Grittner wrote:
On Thu, Apr 17, 2008 at 7:26 PM, Greg Smith wrote:
On this benchmark 2.6.25 is the worst kernel yet:
I don't remember seeing a follow-up on this issue from last year.
Are there still any particular kernels to avoid based on this?
I just
On 4/4/09 9:07 AM, Greg Smith wrote:
On Tue, 31 Mar 2009, Kevin Grittner wrote:
On Thu, Apr 17, 2008 at 7:26 PM, Greg Smith wrote:
On this benchmark 2.6.25 is the worst kernel yet:
I don't remember seeing a follow-up on this issue from last year.
Are there still any particular kernels to
On Sat, 4 Apr 2009, Josh Berkus wrote:
Have you sent this to any Linux kernel engineers? My experience is that
they're fairly responsive to this sort of thing.
I'm going to submit an updated report to LKML once I get back from East, I
want to test against the latest kernel first.
--
*
On Thu, Apr 17, 2008 at 7:26 PM, Greg Smith wrote:
On this benchmark 2.6.25 is the worst kernel yet:
It seems I have a lot of work ahead of me here
to nail down and report what's going on here.
I don't remember seeing a follow-up on this issue from last year.
Are there still any
On Tue, 31 Mar 2009, Kevin Grittner wrote:
On Thu, Apr 17, 2008 at 7:26 PM, Greg Smith wrote:
On this benchmark 2.6.25 is the worst kernel yet:
It seems I have a lot of work ahead of me here
to nail down and report what's going on here.
I don't remember seeing a follow-up on this issue
On Fri, 18 Apr 2008, Matthew wrote:
So what happens if you run pgbench on a separate machine to the server?
Does the problem still exist in that case?
It does not. At the low client counts, there's a big drop-off relative to
running on localhost just because of running over the network.
On Fri, 18 Apr 2008, Tom Lane wrote:
Yeah, it's starting to be obvious that we'd better not ignore sysbench
as not our problem. Do you have any roadmap on what needs to be done
to it?
Just dug into this code again for a minute and it goes something like
this:
1) Wrap the write statements
On Thu, 17 Apr 2008, I wrote:
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'
On Fri, 18 Apr 2008, Matthew wrote:
You may also be seeing processes forced to switch between CPUs, which
breaks the caches even more. So what happens if you run pgbench on a
separate machine to the server? Does the problem still exist in that
case?
I haven't run that test yet but will
This week I've finished building and installing OSes on some new hardware
at home. I have a pretty standard validation routine I go through to make
sure PostgreSQL performance is good on any new system I work with. Found
a really strange behavior this time around that seems related to changes
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
On Thu, Apr 17, 2008 at 12:58 AM, Greg Smith [EMAIL PROTECTED] 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.
This has been discussed recently on linux-kernel. It's definitely a
regression.
On Thu, 17 Apr 2008, Jeffrey Baker wrote:
On Thu, Apr 17, 2008 at 12:58 AM, Greg Smith [EMAIL PROTECTED] 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.
This has been discussed recently on
On Thu, 17 Apr 2008, Jeffrey Baker wrote:
This has been discussed recently on linux-kernel.
Excellent pointer, here's direct to the interesting link there:
http://marc.info/?l=linux-kernelm=120574906013029w=2
Ingo's test system has 16 cores and dives hard at 32 clients; my 4-core
system
On Thu, 17 Apr 2008, Matthew wrote:
The last message in the thread says that 2.6.25-rc6 has the problem nailed.
That was a month ago. So I guess, upgrade to 2.6.25, which was released
today.
Ah, even more support for me to distrust everything I read. The change
has flattened out things, so
On Thu, 17 Apr 2008, Greg Smith wrote:
On Thu, 17 Apr 2008, Matthew wrote:
The last message in the thread says that 2.6.25-rc6 has the problem nailed.
That was a month ago. So I guess, upgrade to 2.6.25, which was released
today.
Ah, even more support for me to distrust everything I read.
On Thu, 17 Apr 2008, [EMAIL PROTECTED] wrote:
report this to the kernel list so that they know, and be ready to test fixes.
Don't worry, I'm on that. I'm already having enough problems with
database performance under Linux, if they start killing results on the
easy benchmarks I'll really
Greg Smith [EMAIL PROTECTED] writes:
This is what happens when the kernel developers are using results from a
MySQL tool to optimize things I guess. It seems I have a lot of work
ahead of me here to nail down and report what's going on here.
Yeah, it's starting to be obvious that we'd
18 matches
Mail list logo
