Re: Scaling shared buffer eviction
От | Amit Kapila |
---|---|
Тема | Re: Scaling shared buffer eviction |
Дата | |
Msg-id | CAA4eK1LFxvfuef_7N_Lo43d6-Nu1Kw08MgNUeL3x1mnU6TharQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Scaling shared buffer eviction (Peter Geoghegan <pg@heroku.com>) |
Список | pgsql-hackers |
On Sat, May 17, 2014 at 6:29 AM, Peter Geoghegan <pg@heroku.com> wrote:
>
>
> On Fri, May 16, 2014 at 7:51 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>>
>> shared_buffers= 8GB
>> scale factor = 3000
>> RAM - 64GB
>
> I'm having a little trouble following this. These figure are transactions per second for a 300 second pgbench tpc-b run?
>
>
> On Fri, May 16, 2014 at 7:51 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>>
>> shared_buffers= 8GB
>> scale factor = 3000
>> RAM - 64GB
>
> I'm having a little trouble following this. These figure are transactions per second for a 300 second pgbench tpc-b run?
Yes, the figures are tps for a 300 second run.
It is for select-only transactions.
What does "Thrds" denote?
It denotes number of threads (-j in pgbench run)
I have used below statements to take data
./pgbench -c 64 -j 64 -T 300 -S postgres
./pgbench -c 64 -j 64 -T 300 -S postgres
./pgbench -c 128 -j 128 -T 300 -S postgres
The reason for posting the numbers for 64/128 threads is because we have
mainly concurrency bottleneck when the number of connections are higher
than CPU cores and I am using 16 cores, 64 hardware threads m/c.
В списке pgsql-hackers по дате отправления: