Re: Some performance degradation in REL_16 vs REL_15

Поиск
Список
Период
Сортировка
От Anton A. Melnikov
Тема Re: Some performance degradation in REL_16 vs REL_15
Дата
Msg-id 8a328367-1788-4c2a-9505-1e62a588e0e8@postgrespro.ru
обсуждение исходный текст
Ответ на Re: Some performance degradation in REL_16 vs REL_15  ("Anton A. Melnikov" <a.melnikov@postgrespro.ru>)
Список pgsql-hackers
On 26.12.2023 07:38, Anton A. Melnikov wrote:
> The results obtained on server seems more reliable as they are consistent with the previous ones
> but i would like to figure out why i don’t see a difference in TPS on my PC.

Seems i found the solution.
Since the possible reason could be an I/O bottleneck, as firstly pointed by Thomas in [1] in similar measurements,
i took on my PC the same approach as in this thread [2] using a 12GB ramdisk from 64GB of my total RAM.

The REL_10_STABLE at c18c12c983 gives ~6900+-100 TPS (+-1.4%), while
REL_16_STABLE at 07494a0df gives ~7200+-90 TPS (+-1.3%). See raw data in the raw-myPC.txt
and graphical representation in the 16vs10-mypc.png

REL_16_STABLE is faster than REL_10_STABLE by ~4%.
So the results on my PC became in consistent with the ones obtained on the server.

Also i performed comparative measurements on the server with ramdrive for all current versions as of January 27th.
Please, see the dependence of the average TPS on the version number at the 10-to-master.png graph.
The raw data are here: raw-server.txt

Brief results are as follows:
1) Differences between 12th, 13th, 14th, 15th and master are subtle and within ~1%.
2) 11th slower than 12th..master by ~2%
3) 10th slower than 12th..master by ~4%
The standard deviation in all measurements except 10th and 11th was ~0.3%, for 11th ~0,4%, for 10th ~0,5%.

Thus, the problem in the subject of this thread is actually not relevant, there is no performance
degradation in REL_16 vs REL_15.

But i'm worried about such a question. If we do not take into account possible fluctuations of a few percent
from commit to commit we can gradually accumulate a considerable loss in performance without noticing it.
And then it will be quite difficult to establish its origin.
Perhaps i'm missing something here. If there any thoughts on this question
would be glad to take them into account.


With the best wishes!

-- 
Anton A. Melnikov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

[1] https://www.postgresql.org/message-id/98646b96-6dcf-8d8a-3daf-837f25f8b1e3%40enterprisedb.com
[2] https://www.postgresql.org/message-id/a74b5a91-d7c1-4138-86df-371c5e2b2be3%40postgrespro.ru


Вложения

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

Предыдущее
От: shveta malik
Дата:
Сообщение: Re: Synchronizing slots from primary to standby
Следующее
От: Dean Rasheed
Дата:
Сообщение: Re: bug report: some issues about pg_15_stable(8fa4a1ac61189efffb8b851ee77e1bc87360c445)