Обсуждение: postgres & smp
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
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
Thomas Graichen <news-list.pgsql.admin@innominate.de> writes:
> 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
Hm, did you set commit_delay to zero? What are the other postmaster
parameters (especially -B) ?
regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Thomas Graichen <news-list.pgsql.admin@innominate.de> writes:
>> 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
> Hm, did you set commit_delay to zero? What are the other postmaster
> parameters (especially -B) ?
i used 32 clients -N set to 128 and -B to 256 - commit_delay was
set to 5 (default) - do you expect much better smp results with
commit_delay=0? what exaclty does commit_delay=0 mean or where
can i find docs about this (and some of the other new parameters)?
again - a lot of thanks in advance
t
--
thomas.graichen@innominate.com
innominate AG
the linux architects
tel: +49-30-308806-13 fax: -77 http://www.innominate.com
Thomas Graichen <news-list.pgsql.admin@innominate.de> writes:
> Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Hm, did you set commit_delay to zero? What are the other postmaster
>> parameters (especially -B) ?
> i used 32 clients -N set to 128 and -B to 256 - commit_delay was
> set to 5 (default) - do you expect much better smp results with
> commit_delay=0?
Possibly. See adjacent thread about 7.1b4 performance.
regards, tom lane