Телеграмм чат группы PostgreSQL_1C

https://www.postgresql.org/docs/12/wal-reliability.html
....
If you have file-system software that prevents partial page writes (e.g., ZFS), you can turn off this page imaging by turning off the full_page_writes parameter.

Ок, вопросов нет

09:48пожаловаться #1

СГ

))

09:48пожаловаться #2

L K in PostgreSQL + 1C + Linux

Alexey Fedotov

давно дело было?

Может с год назад

09:48пожаловаться #3

там есть про отключение checksum в инстансе. А бенчи я делал у себя на pg_bench. Страдают в первую очередь инсёрты:

root@sql# time /opt/pgpro/1c-11/bin/pgbench -U postgres -i -s 1000 pgbench
....
100000000 of 100000000 tuples (100%) done (elapsed 76.33 s, remaining 0.00 s)
vacuuming...
creating primary keys...
done.

real  4m54.682s
user  0m13.867s
sys  0m0.314s

root@sql# time /opt/pgpro/1c-11/bin/pgbench -U postgres -i -s 1000 pgbench
....
100000000 of 100000000 tuples (100%) done (elapsed 67.62 s, remaining 0.00 s)
vacuuming...
creating primary keys...
done.

real  2m14.153s
user  0m14.322s
sys  0m0.364s

второй результат это на кластере с отключенными чексуммами

Такая деградация - это с выключенным fpw?

09:50пожаловаться #4

СГ

Такая деградация - это с выключенным fpw?

вот сейчас уже не скажу - тестировал достаточно давно и какие опции были включены дополнительно не помню. Но разница между именно этими двумя выполненными тестами была только в одном - включеные чек-суммы и выключенные на инстансе. Я предположил что это именно эффект первоначального расчёта chksum при вставке.

09:52пожаловаться #5

СГ

.... надо бы мне найти время и перемерять уже на 12ой версии чтобы точно убедиться и измерить эффект от контрольных сумм

09:54пожаловаться #6

Я вангую, что если вынести wal на xfs/ext4, то деградация сильно уменьшится

09:55пожаловаться #7

СГ

Я вангую, что если вынести wal на xfs/ext4, то деградация сильно уменьшится

я попробую проверить и такой вариант. даже в ram его вынесу для целей эксперимента)
главное найти время и относительно свободную машину для этого

09:57пожаловаться #8

В рам не надо, если в рам, то, конечно, будет быстро

09:58пожаловаться #9

СГ

В рам не надо, если в рам, то, конечно, будет быстро

ну тогда и будет виден эффект от чексумм, который они оказывают на cpu

09:58пожаловаться #10

СГ

или если разница будет в статпогрешности, то значит нет вообще оверхеда

09:58пожаловаться #11

ну тогда и будет виден эффект от чексумм, который они оказывают на cpu

Нет, это будет некорректное сравнение, потому что вместе с чексуммами мы убрали и время записи на диск

09:59пожаловаться #12

Мы этот результат ни с чем не сможем сравнить

10:00пожаловаться #13

Надо или оба измерения производить в рам, или ни одного

10:00пожаловаться #14

СГ

Нет, это будет некорректное сравнение, потому что вместе с чексуммами мы убрали и время записи на диск

почему? Ведь речь про оценку влияния чек-сумм в инстансе. Расчёт чек-сумм это в первую очередь влияние на cpu. данных при этом пишется не больше и не меньше

10:01пожаловаться #15

Это гипотеза, её ещё надо подтвердить

10:02пожаловаться #16

Скорость записи на диск - константа, но в первом замере она присутствует в результате, а во втором - нет

10:03пожаловаться #17

СГ

Это гипотеза, её ещё надо подтвердить

мне даже стало самому интересно, как чек суммы могут повлиять на производительность дискового ввода/вывода

10:03пожаловаться #18

Андрей in PostgreSQL + 1C + Linux

мне даже стало самому интересно, как чек суммы могут повлиять на производительность дискового ввода/вывода

ну как, данные на диске, соответственно он читает данные и потом cpu высчитывает чек-сумму

10:25пожаловаться #19

СГ

Андрей

ну как, данные на диске, соответственно он читает данные и потом cpu высчитывает чек-сумму

данные он читает в любом случае. Пройти алгоритмом по прочитанным данным - это cpu