Thread: postgres & smp

postgres & smp

From
Thomas Graichen
Date:
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

Re: postgres & smp

From
Thomas Graichen
Date:
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

Re: postgres & smp

From
Tom Lane
Date:
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

Re: postgres & smp

From
Thomas Graichen
Date:
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

Re: postgres & smp

From
Tom Lane
Date:
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