Re: refactoring basebackup.c

Поиск
Список
Период
Сортировка
От Dipesh Pandit
Тема Re: refactoring basebackup.c
Дата
Msg-id CAN1g5_HOegxD5qWiMhJyuAZEmJm0CYtSk7wJYuDVXiWjTcVZFA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: refactoring basebackup.c  (Suraj Kharage <suraj.kharage@enterprisedb.com>)
Ответы Re: refactoring basebackup.c  (Suraj Kharage <suraj.kharage@enterprisedb.com>)
Список pgsql-hackers
Дерево обсуждения
Hi,

I have repeated the experiment with 8K block size and found that the results are not varying much after applying the patch.
Please find the details below.

Backup type: local backup using pg_basebackup
Data size: Around 200GB (200 tables - each table around 1.05 GB)
TAR_SEND_SIZE value: 8kb

Server details:
RAM: 500 GB CPU details: Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 128 Filesystem: ext4

Results:

IterationWIthout refactor
patch		WIth refactor
patch
1st runreal 10m19.001s
user 1m37.895s
sys 8m33.008s		real 9m45.291s
user 1m23.192s
sys 8m14.993s
2nd runreal 9m33.970s
user 1m19.490s
sys 8m6.062s		real 9m30.560s
user 1m22.124s
sys 8m0.979s
3rd runreal 9m19.327s
user 1m21.772s
sys 7m50.613s		real 8m59.241s
user 1m19.001s
sys 7m32.645s
4th runreal 9m56.873s
user 1m22.370s
sys 8m27.054s		real 9m52.290s
user 1m22.175s
sys 8m23.052s
5th runreal 9m45.343s
user 1m23.113s
sys 8m15.418s		real 9m49.633s
user 1m23.122s
sys 8m19.240s

Later I connected with Suraj to validate the experiment details and found that the setup and steps followed are exactly the same in this
experiment when compared with the previous experiment.

Thanks,
Dipesh

On Thu, May 14, 2020 at 7:50 AM Suraj Kharage <suraj.kharage@enterprisedb.com> wrote:
Hi,

On Wed, May 13, 2020 at 7:49 PM Robert Haas <robertmhaas@gmail.com> wrote:

So the patch came out slightly faster at 8kB and slightly slower in the other tests. That's kinda strange. I wonder if it's just noise. How much do the results vary run to run?
It is not varying much except for 8kB run. Please see below details for both runs of each scenario.

8kb 32kb (default value)128kB1024kB
WIthout refactor
patch		1st runreal 10m50.924s
user 1m29.774s
sys 9m13.058s		real 8m36.245s
user 1m8.471s
sys 7m21.520s		real 7m8.690s
user 0m54.840s
sys 6m1.725s		real 18m16.898s
user 1m39.105s
sys 9m42.803s
2nd runreal 10m22.718s
user 1m23.629s
sys 8m51.410s		real 8m44.455s
user 1m7.896s
sys 7m28.909s		real 6m54.299s
user 0m55.690s
sys 5m46.502s		real 18m3.511s
user 1m38.197s
sys 9m36.517s
WIth refactor
patch		1st runreal 10m11.350s
user 1m25.038s
sys 8m39.226s		real 8m56.226s
user 1m9.774s
sys 7m41.032s		real 7m26.678s
user 0m54.833s
sys 6m20.057s		real 19m5.218s
user 1m44.122s
sys 10m17.623s
2nd runreal 11m30.500s
user 1m45.221s
sys 9m37.815s		real 9m4.103s
user 1m6.893s
sys 7m49.393s		real 7m26.713s
user 0m54.868s
sys 6m19.652s		real 18m17.230s
user 1m42.749s
sys 9m53.704s
 

--
--

Thanks & Regards, 
Suraj kharage, 
EnterpriseDB Corporation, 
The Postgres Database Company.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Dilip Kumar
Дата:
Сообщение: Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: track_planning causing performance regression