From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Alan Stange <stange(at)rentec(dot)com> |
Cc: | josh(at)agliodbs(dot)com, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Excessive context switching on SMP Xeons |
Date: | 2004-10-06 07:44:02 |
Message-ID: | 87acv0z3y5.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Alan Stange <stange(at)rentec(dot)com> writes:
> A few quick random observations on the Xeon v. Opteron comparison:
>
> - running a dual Xeon with hyperthreading turned on really isn't the same as
> having a quad cpu system. I haven't seen postgresql specific benchmarks, but
> the general case has been that HT is a benefit in a few particular work
> loads but with no benefit in general.
Part of the FUD with hyperthreading did have a kernel of truth that lied in
older kernels' schedulers. For example with Linux until recently the kernel
can easily end up scheduling two processes on the two virtual processors of
one single physical processor, leaving the other physical processor totally
idle.
With modern kernels' schedulers I would expect hyperthreading to live up to
its billing of adding 10% to 20% performance. Ie., a dual Xeon machine with
hyperthreading won't be as fast as four processors, but it should be 10-20%
faster than a dual Xeon without hyperthreading.
As with all things that will only help if you're bound by the right limited
resource to begin with. If you're I/O bound it isn't going to help. I would
expect Postgres with its heavy demand on memory bandwidth and shared memory
could potentially benefit more than usual from being able to context switch
during pipeline stalls.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Ole Langbehn | 2004-10-06 09:30:58 | sequential scan on select distinct |
Previous Message | HyunSung Jang | 2004-10-06 07:31:08 | why my query is not using index?? |