A multi CUP performance problem

Centuries ago, Nostradamus foresaw when liyuexin@neusoft.com (Li YueXin) would write:

I found postgresql running on the multi CPU machine doesn't have
better performance than single CPU machine. Can you explain the
reason? And how to resolve the problem?

The classic reason for this is that if your system is primarily I/O
bound, adding extra CPUs is likely to have a relatively negligible
effect on system performance.

The far-and-away most enormous increase in transactions-per-second
that people seem to see from hardware changes come from putting in a
SCSI controller with large amounts of battery-backed cache.
Additional disk drives tends to be #2. More memory also helps.

The "problem" might very well be your expectation that adding CPUs
would necessarily have much effect on performance.
--
output = ("cbbrowne" "@" "cbbrowne.com")
http://www3.sympatico.ca/cbbrowne/emacs.html
DSK: STAN.K; ML EXIT -- FILE NOT FOUND

On Tue, 2003-09-23 at 22:45, Li YueXin wrote:

I found postgresql running on the multi CPU machine doesn't have
better performance than single CPU machine. Can you explain the
reason?

In addition to what Christopher Browne suggests, keep in mind that
PostgreSQL spawns a separate Unix process for each client connection.
Since each process can run on at most one CPU at any given time, if the
# of concurrent queries your application submits is < than the # of CPUs
in the machine, PostgreSQL won't take advantage of all your CPUs.

It would be possible to spread the execution of a single query over
multiple CPUs (say, have different nodes in the query tree execute on
different CPUs concurrently), but I highly doubt PostgreSQL will bother
doing that anytime soon.

-Neil

Li YueXin <liyuexin@neusoft.com> writes:

I found postgresql running on the multi CPU machine doesn't have
better performance than single CPU machine. Can you explain the
reason?

That's a rather sweeping statement to make without offering any
evidence, I should think.

If you gave details --- "I did x,y,z, on thus-and-such a platform,
and couldn't see any speedup" --- then you might get useful responses.

regards, tom lane

Not exactly, I think.

It said that postgresql "Add code to detect an SMP machine and handle spinlocks accordingly", so it is an issue of spinlock handling, not the distribution of execution tree.

In SMP enviorment, when using spinlock, when we fail to get the spin lock at a time, we may do a number of null loops to try to see if another threads on another cpu release the spin lock. It is just like M$'s EnterCriticalSection system call's last parameter.

Am I right?

======= 2003-09-24 00:09:00 You Wrote: =======

On Tue, 2003-09-23 at 22:45, Li YueXin wrote:

I found postgresql running on the multi CPU machine doesn't have
better performance than single CPU machine. Can you explain the
reason?

In addition to what Christopher Browne suggests, keep in mind that
PostgreSQL spawns a separate Unix process for each client connection.
Since each process can run on at most one CPU at any given time, if the
# of concurrent queries your application submits is < than the # of CPUs
in the machine, PostgreSQL won't take advantage of all your CPUs.

It would be possible to spread the execution of a single query over
multiple CPUs (say, have different nodes in the query tree execute on
different CPUs concurrently), but I highly doubt PostgreSQL will bother
doing that anytime soon.

-Neil

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

= = = = = = = = = = = = = = = = = = = =

Yours Sincerely,

　　　　　　　　Hu Tian-Lei
　　　　　　　　andy_hu@263.net
　　　　　　　　　　2003-09-24