just to avoid confusion - some more things:
* smp and up case compared here were done on the same machine
(linux 2.4.1-XFS, smp kernel booted with or without "nosmp")
* the used hardware is a 2 pII333 128mb ide disk
* the numbers were generated using pgbench from postgres-7.1beta4
with -c 32 -s 20 -t 100
* the results are ranging from ~17tps (reiserfs/smp) ... ~20-23tps
(xfs/smp-up)
one idea i have so far is that the pgbench queries are that simple
that the whole benchmark is heavily disk bound and the second cpu
only results in locking overhead resulting in a bit lower numbers)
may this be the reason for the missing improvement in the numbers
in the smp case?
again - a lot of thanks in advance
t
Thomas Graichen <news-list.pgsql.admin@innominate.de> wrote:
> i hope this list is somewhat the right one for this ...
> i did some small tests with postgresql-71.beta4 on various
> filesystems (ext2, reiserfs, xfs) on two machines: 1 single
> cpu and one 2 cpu smp and was a bit surprised to see the tps
> results of the smp case to be lower than the one of the up case
> (also the running times of the used pgbench said the same)
> ... i was thinking that the load should spread over the cpu's
> and thus expected better results for smp - is there anything
> to take care of for smp with postgresql? did i anything
> wrong here?
> a lot of thanks in advance
> t
> p.s.: btw. i in all cases see about 15% better results with
> the database running on an xfs filesystem compared to
> ext2 ... reiserfs is about the same as ext2 but some-
> times even worse ... just if anyone is interested ...
> --
> thomas.graichen@innominate.com
> innominate AG
> the linux architects
> tel: +49-30-308806-13 fax: -77 http://www.innominate.com
--
thomas.graichen@innominate.com
innominate AG
the linux architects
tel: +49-30-308806-13 fax: -77 http://www.innominate.com