Re: Question about LWLockAcquire's use of semaphores instead
От | Luis Alberto Amigo Navarro |
---|---|
Тема | Re: Question about LWLockAcquire's use of semaphores instead |
Дата | |
Msg-id | 002b01c237b2$5d726680$cab990c1@atc.unican.es обсуждение исходный текст |
Ответ на | Re: Question about LWLockAcquire's use of semaphores instead (Bruce Momjian <pgman@candle.pha.pa.us>) |
Ответы |
Re: Question about LWLockAcquire's use of semaphores instead
|
Список | 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
В списке pgsql-hackers по дате отправления: