Re: [HACKERS] a tiny question
I supposed it, but I've not seen 7.3. A small patch for low performance on NUMA arquitectures could be the chance of using more than one shared region. Several months away there was a brief talk about low performance on IRIX, it was not real, it's low performance on Origin servers, they use ccNUMA architecture, so using a single shared segment allocated by only one proccess doesn't give IRIX planner a chance for attempting to optimize memory accesses, even thought page migration is almost impossible with DB memory accesses. With this scenario, IRIX uses a first-touch algorith for memory placement (all the memory is allocated on the node Postgres starts running). Due to high latency between local and remote memory accesses, if there is data modification, remote proccesors cache hit rate goes down, all of this makes that all the basis of high scalability on this systems(big cache, memory distribution, increasing bandwith and page migration) ar thrown to the earth. I suppose that making more than one shared segment it's not too difficult, but with this u can do that a long time Postgres running on a NUMA system achieve a good performance scenario. Is it so difficult? Thanks and regards. Luis Amigo ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] a tiny question
"Luis Alberto Amigo Navarro" <[EMAIL PROTECTED]> writes: > Is there a way to set more than one shared regions? No, there isn't. Cheers, Neil -- Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] a tiny question
Another "tiny" question: Is there a way to set more than one shared regions? Thanks and regards ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] a tiny question
a guess it's said inter-locking, I mean data accessed exclusively. I apologize for my english - Original Message - From: "Neil Conway" <[EMAIL PROTECTED]> To: "Luis Alberto Amigo Navarro" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, November 05, 2002 4:47 PM Subject: Re: [HACKERS] a tiny question > "Luis Alberto Amigo Navarro" <[EMAIL PROTECTED]> writes: > > When we improve seq scans, systems scales well up to 8 cpus.When we improve index > > scan, query performance increase but system stops scaling at about 4 proccessors, > > profiling shows that it is due to increased memory contention > > What do you mean by "memory contention"? > > Cheers, > > Neil > > -- > Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC > > > ---(end of broadcast)--- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org > > ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] a tiny question
"Luis Alberto Amigo Navarro" <[EMAIL PROTECTED]> writes: > When we improve seq scans, systems scales well up to 8 cpus.When we improve index > scan, query performance increase but system stops scaling at about 4 proccessors, > profiling shows that it is due to increased memory contention What do you mean by "memory contention"? Cheers, Neil -- Neil Conway <[EMAIL PROTECTED]> || PGP Key ID: DB3C29FC ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] a tiny question
Hi all: I've been running small aplications over postgres 7.2.2, they are based over a tpch-like 100Mb database (which give us about 400Mb of disk usage), system is an 8-CPU SGI Power Challenge, postgres is given 8 shared buffers and backends 32Mb of sort-memory, so all data fits in memory and we avoid disk accesses. When we improve seq scans, systems scales well up to 8 cpus.When we improve index scan, query performance increase but system stops scaling at about 4 proccessors, profiling shows that it is due to increased memory contention, it seems strange cause query are all read only, at the beggining of the run we insert and delete some rows, but it is only 1/10 of the time. All of that is first of all to advise of this performance drop, and second to ask what is the difference between memory usage with seqscans and indexscans. Thanks and regards
