Re: checkpointer continuous flushing
От | Fabien COELHO |
---|---|
Тема | Re: checkpointer continuous flushing |
Дата | |
Msg-id | alpine.DEB.2.10.1601160945320.18181@sto обсуждение исходный текст |
Ответ на | Re: checkpointer continuous flushing (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: checkpointer continuous flushing
|
Список | pgsql-hackers |
Hello Andres, > I measured it in a different number of cases, both on SSDs and spinning > rust. I just reproduced it with: > > postgres-ckpt14 \ > -D /srv/temp/pgdev-dev-800/ \ > -c maintenance_work_mem=2GB \ > -c fsync=on \ > -c synchronous_commit=off \ > -c shared_buffers=2GB \ > -c wal_level=hot_standby \ > -c max_wal_senders=10 \ > -c max_wal_size=100GB \ > -c checkpoint_timeout=30s > > Using a fresh cluster each time (copied from a "template" to save time) > and using > pgbench -M prepared -c 16 -j 16 -T 300 -P 1 I'm running some tests similar to those above... Do you do some warmup when testing? I guess the answer is "no". I understand that you have 8 cores/16 threads on your host? Loading scale 800 data for 300 seconds tests takes much more than 300 seconds (init takes ~360 seconds, vacuum & index are slow). With 30 seconds checkpoint cycles and without any warmup, I feel that these tests are really on the very short (too short) side, so I'm not sure how much I can trust such results as significant. The data I reported were with more real life like parameters. Anyway, I'll have some results to show with a setting more or less similar to yours. -- Fabien.
В списке pgsql-hackers по дате отправления: