|
On 4/10/19 6:03 PM, Rene Romero
Benavides wrote:
What's your current max_wal_size parameter?
SHOW max_wal_size;
If it's 8GB as your configuration's previous value, you
would get a constant share of 512 WAL files. If it's a
development environment set it to the desired size, the
smaller the value, the more frequent the checkpoints, but your
checkpoint_timeout value is 300 (5 minutes) which is likely to
be happening first, and thus being the one triggering
checkpoints that often.
As per your configuration :
max_wal_size = 50GB
this seems to be the cause for the WAL files
piling up.
this has been declared twice, the last one is
taking effect.
--
I've manage to generate another 359 WAL files in a 10
minute span yesterday (now only 357 remain and I suspect
they will wither away as before). Are these being held
simply because of the high max_wal_size value?
This is a development environment, wherein I'm
loading 4M+ records, first into 41 staging tables 100K
rows per. In a loop over each staging table, the data
is then placed into application tables via selects.
First select * into "matching table" then select id into
intersection record (id, fixed groupId). Each such
iteration is in it's own transaction. I have dropped
and recreate this same database numerous times working
my way up from 100K to 4M records, dialing in
application parameters according to number of primary
records. I have not, however, dropped the last
incarnation.
We have not yet reconfigured the max_wal_size parameter, it is
still 50GB
postgres-# show max_wal_size
postgres-# ;
max_wal_size
--------------
50GB
(1 row)
I'm sorry, I don't follow your thesis that this setting would
lead to "a constant" 512 WAL files. There was a distinct burst of
WALs in a 10 minute period yesterday, and no accumulation since
then (though a manual checkpoint does generate another WAL)
|
