From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Mindaugas Riauba <mind(at)bi(dot)lt> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Dual Xeon + HW RAID question |
Date: | 2003-07-22 16:26:01 |
Message-ID: | 200307221626.h6MGQ1824547@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Mindaugas Riauba wrote:
>
> > > I missed your orig. post, but AFAIK multiprocessing kernels will handle
> HT
> > > CPUs as 2 CPUs each. Thus, our dual Xeon 2.4 is recognized as 4 Xeon 2.4
> > > CPUs.
> > >
> > > This way, I don't think HT would improve any single query (afaik no
> postgres
> > > process uses more than one cpu), but overall multi-query performance has
> to
> > > improve.
> >
> > When you use hyperthreading, each virtual cpu runs at 70% of a full CPU,
> > so hyperthreading could be slower than non-hyperthreading. On a fully
> > loaded dual cpu system, you are looking at 2.8 cpu's (0.70 * 4), while
> > if it isn't loaded, you are looking at slowing down if you are only
> > using 1 or 2 cpu's.
>
> Virtual cpus are not running at 70% of real cpus :). Slowdown will happen
> if
> scheduler will run 2 processes on the same real cpu. And I read that there
> are
> patches for Linux kernel to fix that. Sooner rather than later they will
> appear
> in Linus kernel.
Right, I simplified it. The big deal is whether the OS favors the
second real CPU over one of the virtual CPU's on the same die --- by
default, it doesn't. Ever if it did work perfectly, you are talking
about going from 1 to 1.4 or 2 to 2.8, which doesn't seem like much.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
From | Date | Subject | |
---|---|---|---|
Next Message | Mendola Gaetano | 2003-07-22 17:10:14 | Wrong plan or what ? |
Previous Message | Vivek Khera | 2003-07-22 16:12:54 | Re: Tuning PostgreSQL |