On 01/30/2015 04:48 AM, Venkata Balaji N wrote:
> I performed series of tests for this patch and would like to share the
> results. My comments are in-line.
Thanks for the testing!
> *Test 1 :*
>
> In this test, i see removed+recycled segments = 3 (except for the first 3
> checkpoint cycles) and has been steady through out until the INSERT
> operation completed.
>
> Actual calculation of CheckPointSegments = 3.2 ( is getting rounded up to 3
> )
>
> pg_xlog size is 128M and has increased to 160M max during the INSERT
> operation.
>
> shared_buffers = 128M
> checkpoint_wal_size = 128M
> min_recycle_wal_size = 80M
> checkpoint_timeout = 5min
Hmm, did I understand correctly that pg_xlog peaked at 160MB, but most
of the stayed at 128 MB? That sounds like it's working as designed;
checkpoint_wal_size is not a hard limit after all.
>> b) Are the two GUCs, checkpoint_wal_size, and min_recycle_wal_size,
>> intuitive to set?
>
> During my tests, I did not observe the significance of min_recycle_wal_size
> parameter yet. Ofcourse, i had sufficient disk space for pg_xlog.
>
> I would like to understand more about "min_recycle_wal_size" parameter. In
> theory, i only understand from the note in the patch that if the disk space
> usage falls below certain threshold, min_recycle_wal_size number of WALs
> will be removed to accommodate future pg_xlog segments. I will try to test
> this out. Please let me know if there is any specific test to understand
> min_recycle_wal_size behaviour.
min_recycle_wal_size comes into play when you have only light load, so
that checkpoints are triggered by checkpoint_timeout rather than
checkpoint_wal_size. In that scenario, the WAL usage will shrink down to
min_recycle_wal_size, but not below that. Did that explanation help? Can
you suggest changes to the docs to make it more clear?
- Heikki