Обсуждение: Hyper-Trading
Hello ! How to force POSTGRES to use all virtual processors at included Hyper-Trading ? -- С уважением, Евгений Кононов Администратор ООО "Технопросистем". mailto:kononov@office.tps.uz
On 7/7/07, Евгений Кононов <kononov@office.tps.uz> wrote: > Hello ! Hi Evgenij, > How to force POSTGRES to use all virtual processors at included > Hyper-Trading ? What OS are you using, and what's hyper-trading? Hyper threading by any chance? That's the OSes responsibility, not the databases. > -- > С уважением, > Евгений Кононов Cheers, Andrej -- Please don't top post, and don't use HTML e-Mail :} Make your quotes concise. http://www.american.edu/econ/notes/htmlmail.htm
On Saturday 07 July 2007 11.34:04 Евгений Кононов wrote: > Hello ! > > How to force POSTGRES to use all virtual processors at included > Hyper-Trading ? If your operating system is able to schedule the threads/processes across CPUs, PostgreSQL will use them. Often, the limit is disk, not CPU, so check this first if you feel your db should be running faster than it does. greetings -- vbi -- this email is protected by a digital signature: http://fortytwo.ch/gpg
On 7/10/07, Евгений Кононов <kononov@office.tps.uz> wrote: > Здравствуйте, Andrej. Privet ;) ... not that I speak any Russian, really. >> ARB> What OS are you using, and what's hyper-trading? Hyper threading >> ARB> by any chance? That's the OSes responsibility, not the databases. > I'm use Fedora Core 5, based on two Intel(R) Xeon(TM) MP CPU 3.16GHz > processors with Hyper-Trading technology. It means, that I use 4 > virtual processors. > And, then I run postgreSQL, he use only one processor and work very > easy. I want to use postgreSQL on all my processors, but I don't know > how did it. As I said ... if the OS supports those hyperthreaded CPUs properly (I assume you're seing four CPUs in /proc/cpuinfo?) and you fire up concurrent connections to the database the OS should start spreading the load across CPUs. It's not the databases task (or capability) to make that decision. > Thank's ! Cheers, Andrej
On Tue, Jul 10, 2007 at 08:09:11PM +0200, Adrian von Bidder wrote:
> If your operating system is able to schedule the threads/processes across
> CPUs, PostgreSQL will use them.
But notice that hyperthreading imposes its own overhead. I've not
seen evidence that enabling hyperthreading actually helps, although I
may have overlooked a couple of cases.
A
--
Andrew Sullivan | ajs@crankycanuck.ca
I remember when computers were frustrating because they *did* exactly what
you told them to. That actually seems sort of quaint now.
--J.D. Baldwin
On 7/11/07, Andrew Sullivan <ajs@crankycanuck.ca> wrote: > On Tue, Jul 10, 2007 at 08:09:11PM +0200, Adrian von Bidder wrote: > > > If your operating system is able to schedule the threads/processes across > > CPUs, PostgreSQL will use them. > > But notice that hyperthreading imposes its own overhead. I've not > seen evidence that enabling hyperthreading actually helps, although I > may have overlooked a couple of cases. I don't have any metrics of my own to present (nor do I care enough to try and gather them), but there are a few tests with kind of varied results, depending on WHAT one wants to use HT for. Have a look at these: http://www.ibm.com/developerworks/linux/library/l-htl/ http://www.2cpu.com/articles/41_6.html In how far they're relevant to Postgres is left as an exercise to the reader :} > A Cheers, Andrej -- Please don't top post, and don't use HTML e-Mail :} Make your quotes concise. http://www.american.edu/econ/notes/htmlmail.htm
"Andrej Ricnik-Bay" <andrej.groups@gmail.com> writes: > On 7/11/07, Andrew Sullivan <ajs@crankycanuck.ca> wrote: >> But notice that hyperthreading imposes its own overhead. I've not >> seen evidence that enabling hyperthreading actually helps, although I >> may have overlooked a couple of cases. > Have a look at these: > http://www.ibm.com/developerworks/linux/library/l-htl/ > http://www.2cpu.com/articles/41_6.html Conventional wisdom around here has been that HT doesn't help database performance, and that IBM link might provide a hint as to why: the only item for which they show a large loss in performance is disk I/O. Ooops. Personally I keep HT turned on on my devel machine, because I do find that recompiling Postgres is noticeably faster ("make -j4" rocks on a dual Xeon w/HT). I doubt that's the benchmark of greatest interest to the average *user* of Postgres, though. regards, tom lane
On 7/11/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Conventional wisdom around here has been that HT doesn't help database
> performance, and that IBM link might provide a hint as to why: the
> only item for which they show a large loss in performance is disk I/O.
> Ooops.
Thanks Tom, great summary. How does this compare with
SMP vs HT?
> Personally I keep HT turned on on my devel machine, because I do find
> that recompiling Postgres is noticeably faster ("make -j4" rocks on a
> dual Xeon w/HT). I doubt that's the benchmark of greatest interest
> to the average *user* of Postgres, though.
Understood :)
> regards, tom lane
Cheers,
Andrej