From: | "Luis Alberto Amigo Navarro" <lamigo(at)atc(dot)unican(dot)es> |
---|---|
To: | "Bruce Momjian" <pgman(at)candle(dot)pha(dot)pa(dot)us>, <bruc(at)acm(dot)org> |
Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Question about LWLockAcquire's use of semaphores instead |
Date: | 2002-07-30 10:17:52 |
Message-ID: | 002b01c237b2$5d726680$cab990c1@atc.unican.es |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> We would have to understand how the SGI code is better than our existing
> code on SMP machines.
there is a big problem with postgres on SGI NUMA architectures, on UMA
systems postgres works fine, but NUMA Origins need a native shared memory
management. It scales fine over old challenges, but scales very poorly on
NUMA architectures, giving fine speed-up only within a single node. For more
than one node throughput drops greatly, implementing Round-robin memory
placement algorithms it gets a bit better, changing from forks to native
sprocs(medium-weighted processes) makes it work better, but not good enough,
if you want postgres to run fine on this machines I think (it's not tested
yet) it would be neccesary to implement native shared arenas instead of IPC
shared memory in order to let IRIX make a fine load-balance.
I take advantage of this message to say that there is a cuple of things that
we have to insert on FAQ-IRIX about using 32 bits or 64 bits objects,
because it is a known issue that using 32 bit objects on IRIX do not allow
to use more than 1,2 Gb of shared memory because system management is unable
to find a single segment of this size.
Regards
From | Date | Subject | |
---|---|---|---|
Next Message | Curt Sampson | 2002-07-30 11:00:13 | Re: Why is MySQL more chosen over PostgreSQL? |
Previous Message | Adrian 'Dagurashibanipal' von Bidder | 2002-07-30 09:51:45 | Re: Why is MySQL more chosen over PostgreSQL? |