Re: Improving connection scalability (src/backend/storage/ipc/procarray.c)

From: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
To: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Improving connection scalability (src/backend/storage/ipc/procarray.c)
Date: 2022-05-25 11:26:21
Message-ID: CAEudQAqAipMdVRpwnuQeSuPReL3Foc_Ay8jmz9iVk-EpRx0a+Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Em qua., 25 de mai. de 2022 às 07:13, Tomas Vondra <
tomas(dot)vondra(at)enterprisedb(dot)com> escreveu:

>
>
> On 5/25/22 11:07, Ranier Vilela wrote:
> > Em qua., 25 de mai. de 2022 às 00:46, Andres Freund <andres(at)anarazel(dot)de
> > <mailto:andres(at)anarazel(dot)de>> escreveu:
> >
> > Hi Andres, thank you for taking a look.
> >
> >
> > On 2022-05-24 12:28:20 -0300, Ranier Vilela wrote:
> > > Linux Ubuntu 64 bits (gcc 9.4)
> > > ./pgbench -M prepared -c $conns -j $conns -S -n -U postgres
> > >
> > > conns tps head tps patched
> > > 1 2918.004085 3190.810466
> > > 10 12262.415696 17199.862401
> > > 50 13656.724571 18278.194114
> > > 80 14338.202348 17955.336101
> > > 90 16597.510373 18269.660184
> > > 100 17706.775793 18349.650150
> > > 200 16877.067441 17881.250615
> > > 300 16942.260775 17181.441752
> > > 400 16794.514911 17124.533892
> > > 500 16598.502151 17181.244953
> > > 600 16717.935001 16961.130742
> > > 700 16651.204834 16959.172005
> > > 800 16467.546583 16834.591719
> > > 900 16588.241149 16693.902459
> > > 1000 16564.985265 16936.952195
> >
> > 17-18k tps is pretty low for pgbench -S. For a shared_buffers
> > resident run, I
> > can get 40k in a single connection in an optimized build. If you're
> > testing a
> > workload >> shared_buffers, GetSnapshotData() isn't the bottleneck.
> And
> > testing an assert build isn't a meaningful exercise either, unless
> > you have
> > way way higher gains (i.e. stuff like turning O(n^2) into O(n)).
> >
> > Thanks for sharing these hits.
> > Yes, their 17-18k tps are disappointing.
> >
> >
> > What pgbench scale is this and are you using an optimized build?
> >
> > Yes this optimized build.
> > CFLAGS='-Wall -Wmissing-prototypes -Wpointer-arith
> > -Wdeclaration-after-statement -Werror=vla -Wendif-labels
> > -Wmissing-format-attribute -Wimplicit-fallthrough=3 -Wcast-function-type
> > -Wformat-security -fno-strict-aliasing -fwrapv
> > -fexcess-precision=standard -Wno-format-truncation
> > -Wno-stringop-truncation -O2'
> > from config.log
> >
>
> That can still be assert-enabled build. We need to see configure flags.
>
./configure
Attached the config.log (compressed)

>
> > pgbench was initialized with:
> > pgbench -i -p 5432 -d postgres
> >
> > pgbench -M prepared -c 100 -j 100 -S -n -U postgres
>
> You're not specifying duration/number of transactions to execute. So
> it's using just 10 transactions per client, which is bound to give you
> bogus results due to not having anything in relcache etc. Use -T 60 or
> something like that.
>
Ok, I will try with -T 60.

>
> > pgbench (15beta1)
> > transaction type: <builtin: select only>
> > scaling factor: 1
> > query mode: prepared
> > number of clients: 100
> > number of threads: 100
> >
> > The shared_buffers is default:
> > shared_buffers = 128MB
> >
> > Intel® Core™ i5-8250U CPU Quad Core
> > RAM 8GB
> > SSD 256 GB
> >
>
> Well, quick results on my laptop (i7-9750H, so not that different from
> what you have):
>
> 1 = 18908.080126
> 2 = 32943.953182
> 3 = 42316.079028
> 4 = 46700.087645
>
> So something is likely wrong in your setup.
>
select version();
version

----------------------------------------------------------------------------------------------------------
PostgreSQL 15beta1 on x86_64-pc-linux-gnu, compiled by gcc (Ubuntu
9.4.0-1ubuntu1~20.04.1) 9.4.0, 64-bit

Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
9.4.0-1ubuntu1~20.04.1'
--with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2
--prefix=/usr --with-gcc-major-version-only --program-suffix=-9
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib=auto --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-9-Av3uEd/gcc-9-9.4.0/debian/tmp-nvptx/usr,hsa
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 9.4.0 (Ubuntu 9.4.0-1ubuntu1~20.04.1)

regards,
Ranier Vilela

Attachment Content-Type Size
config.tar.xz application/x-xz 20.2 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message vignesh C 2022-05-25 11:55:02 Re: Handle infinite recursion in logical replication setup
Previous Message Amit Kapila 2022-05-25 11:26:11 Re: Build-farm - intermittent error in 031_column_list.pl