Size: a a a

PostgreSQL + 1C + Linux

2020 July 10

LK

L K in PostgreSQL + 1C + Linux
Сергей Голод
понял. да, вы правы -  я неправильные взял показатели

P.S. хотя надо бы брать полное время теста)) и тогда разница уже 33% даже для вашего случая
33% это так для вакуума, в реальности при работе если замедление и будет чуствоваться, то ближе к 12%, а совместно с 1с, будет близко к погрешности измернений.
источник

СГ

Сергей Голод... in PostgreSQL + 1C + Linux
L K
33% это так для вакуума, в реальности при работе если замедление и будет чуствоваться, то ближе к 12%, а совместно с 1с, будет близко к погрешности измернений.
а вы дальше проверьте уже не только на создании, но и на pg_bench:
pgbench -U postgres -j 32 -c 32 -M prepared -T 600 pgbench
источник

LK

L K in PostgreSQL + 1C + Linux
У меня 4 ядра на хосте, это будет много.
источник

СГ

Сергей Голод... in PostgreSQL + 1C + Linux
поменяйте параметры под ваши характеристики. важно  ведь сравнение результатов на инстансе с вкл и выкл чексуммами
источник

LK

L K in PostgreSQL + 1C + Linux
Сергей Голод
поменяйте параметры под ваши характеристики. важно  ведь сравнение результатов на инстансе с вкл и выкл чексуммами
Мне интересно сравнить расчет зарплаты на 3000 сотрудников, насколько помню разницы существенной не было.
Нужно перемерить.
источник

СГ

Сергей Голод... in PostgreSQL + 1C + Linux
L K
Мне интересно сравнить расчет зарплаты на 3000 сотрудников, насколько помню разницы существенной не было.
Нужно перемерить.
ну да, вся эта синтетика может оказаться совершенно неприменимой на реальной эксплуатации
источник

LK

L K in PostgreSQL + 1C + Linux
Сергей Голод
а вы дальше проверьте уже не только на создании, но и на pg_bench:
pgbench -U postgres -j 32 -c 32 -M prepared -T 600 pgbench
:/home/user$ time pgbench -j 32 -c 32 -M prepared -T 600 pgbench
starting vacuum...end.
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 1000
query mode: prepared
number of clients: 32
number of threads: 32
duration: 600 s
number of transactions actually processed: 1425678
latency average = 13.469 ms
tps = 2375.790120 (including connections establishing)
tps = 2376.012756 (excluding connections establishing)

real    10m0,334s
user    1m59,212s
sys     3m48,208s


postgres@u2004:/home/user$ time pgbench -j 32 -c 32 -M prepared -T 600 pgbench
starting vacuum...end.
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 1000
query mode: prepared
number of clients: 32
number of threads: 32
duration: 600 s
number of transactions actually processed: 1056430
latency average = 18.178 ms
tps = 1760.353143 (including connections establishing)
tps = 1760.467637 (excluding connections establishing)

real    10m0,289s
user    1m34,845s
sys     3m13,124s
источник

СГ

Сергей Голод... in PostgreSQL + 1C + Linux
L K
:/home/user$ time pgbench -j 32 -c 32 -M prepared -T 600 pgbench
starting vacuum...end.
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 1000
query mode: prepared
number of clients: 32
number of threads: 32
duration: 600 s
number of transactions actually processed: 1425678
latency average = 13.469 ms
tps = 2375.790120 (including connections establishing)
tps = 2376.012756 (excluding connections establishing)

real    10m0,334s
user    1m59,212s
sys     3m48,208s


postgres@u2004:/home/user$ time pgbench -j 32 -c 32 -M prepared -T 600 pgbench
starting vacuum...end.
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 1000
query mode: prepared
number of clients: 32
number of threads: 32
duration: 600 s
number of transactions actually processed: 1056430
latency average = 18.178 ms
tps = 1760.353143 (including connections establishing)
tps = 1760.467637 (excluding connections establishing)

real    10m0,289s
user    1m34,845s
sys     3m13,124s
ну всё таки чексуммы оказывают влияние на производительность
источник

СГ

Сергей Голод... in PostgreSQL + 1C + Linux
или тест был не идеально честный? (нагрузка на комп при выполнении)
источник

LK

L K in PostgreSQL + 1C + Linux
Да нет, сильно не менялось, думаю отражает правду.
источник

GS

Grigory Smolkin in PostgreSQL + 1C + Linux
L K
:/home/user$ time pgbench -j 32 -c 32 -M prepared -T 600 pgbench
starting vacuum...end.
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 1000
query mode: prepared
number of clients: 32
number of threads: 32
duration: 600 s
number of transactions actually processed: 1425678
latency average = 13.469 ms
tps = 2375.790120 (including connections establishing)
tps = 2376.012756 (excluding connections establishing)

real    10m0,334s
user    1m59,212s
sys     3m48,208s


postgres@u2004:/home/user$ time pgbench -j 32 -c 32 -M prepared -T 600 pgbench
starting vacuum...end.
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 1000
query mode: prepared
number of clients: 32
number of threads: 32
duration: 600 s
number of transactions actually processed: 1056430
latency average = 18.178 ms
tps = 1760.353143 (including connections establishing)
tps = 1760.467637 (excluding connections establishing)

real    10m0,289s
user    1m34,845s
sys     3m13,124s
если тестируются чексуммы, то надо или read-only нагрузку давать, или в tmpfs
источник

GS

Grigory Smolkin in PostgreSQL + 1C + Linux
иначе получаете флуктуации от диска
источник

LK

L K in PostgreSQL + 1C + Linux
Сергей Голод
ну всё таки чексуммы оказывают влияние на производительность
Да честно сказать, крепко озадачило, нужно тестить 1с
источник

СГ

Сергей Голод... in PostgreSQL + 1C + Linux
Grigory Smolkin
если тестируются чексуммы, то надо или read-only нагрузку давать, или в tmpfs
не соглашусь. При рид-онли нет расчёта чек-сумм при вставках. есть только проверка, когда страница читается
источник

GS

Grigory Smolkin in PostgreSQL + 1C + Linux
Сергей Голод
не соглашусь. При рид-онли нет расчёта чек-сумм при вставках. есть только проверка, когда страница читается
тогда tmpfs
источник

СГ

Сергей Голод... in PostgreSQL + 1C + Linux
Grigory Smolkin
тогда tmpfs
+++
источник

LK

L K in PostgreSQL + 1C + Linux
Фактически, мерь не мерь, а без ckhecksum +35%
источник

LK

L K in PostgreSQL + 1C + Linux
Grigory Smolkin
тогда tmpfs
Григорий, а без checksum - pg_probackup надежен?
источник

GS

Grigory Smolkin in PostgreSQL + 1C + Linux
L K
Фактически, мерь не мерь, а без ckhecksum +35%
у вас корреляция глобального потепления и кол-ва пиратов
источник

2_

2flower _ in PostgreSQL + 1C + Linux
L K
Фактически, мерь не мерь, а без ckhecksum +35%
Звучит как то печально.
источник