Hi Andres.
> 25 апр. 2017 г., в 7:17, Andres Freund <[email protected]> написал(а):
>
> Hi,
>
> I've lately seen more and more installations where the generation of
> write-ahead-log (WAL) is one of the primary bottlenecks. I'm curious
> whether that's primarily a "sampling error" of mine, or whether that's
> indeed more common.
>
> The primary reason I'm curious is that I'm pondering a few potential
> optimizations, and would like to have some guidance which are more and
> which are less important.
>
> Questions (answer as many you can comfortably answer):
> - How many MB/s, segments/s do you see on busier servers?
Nearly one WAL (16 MB) per second most of the time and 3 WALs per second in the
beginning of checkpoint (due to full_page_writes).
> - What generates the bulk of WAL on your servers (9.5+ can use
> pg_xlogdump --stats to compute that)?
Here is the output from a couple of our masters (and that is actually two hours
before peak load):
$ pg_xlogdump --stats 0000000100012B2800000089 0000000100012B3000000088 | fgrep
-v 0.00
Type N (%) Record size
(%) FPI size (%) Combined size (%)
---- - --- -----------
--- -------- --- ------------- ---
Heap2 55820638 ( 21.31) 1730485085
( 22.27) 1385795249 ( 13.28) 3116280334 ( 17.12)
Heap 74366993 ( 28.39) 2288644932
( 29.46) 5880717650 ( 56.34) 8169362582 ( 44.87)
Btree 84655827 ( 32.32) 2243526276
( 28.88) 3170518879 ( 30.38) 5414045155 ( 29.74)
-------- --------
-------- --------
Total 261933790 7769663301
[42.67%] 10437031778 [57.33%] 18206695079 [100%]
$
$ pg_xlogdump --stats 000000010000D17F000000A5 000000010000D19100000004 | fgrep
-v 0.00
Type N (%) Record size
(%) FPI size (%) Combined size (%)
---- - --- -----------
--- -------- --- ------------- ---
Heap2 13676881 ( 18.95) 422289539
( 19.97) 15319927851 ( 25.63) 15742217390 ( 25.44)
Heap 22284283 ( 30.88) 715293050
( 33.83) 17119265188 ( 28.64) 17834558238 ( 28.82)
Btree 27640155 ( 38.30) 725674896
( 34.32) 19244109632 ( 32.19) 19969784528 ( 32.27)
Gin 6580760 ( 9.12) 172246586
( 8.15) 8091332009 ( 13.54) 8263578595 ( 13.35)
-------- --------
-------- --------
Total 72172983 2114133847
[3.42%] 59774634680 [96.58%] 61888768527 [100%]
$
> - Are you seeing WAL writes being a bottleneck?OA
We do sometimes see WALWriteLock in pg_stat_activity.wait_event, but not too
often.
> - What kind of backup methods are you using and is the WAL volume a
> problem?
We use fork of barman project. In most cases that’s not a problem.
> - What kind of replication are you using and is the WAL volume a
> problem?
Physical streaming replication. We used to have problems with network bandwidth
(1 Gbit/s was consumed by transferring WAL to two replicas and one archive) but
that became better after 1. upgrading to 9.5 and turning wal_compression on, 2.
changing archive command to doing parallel compression and sending WALs to
archive, 3. increasing checkpoint_timeout.
> - What are your settings for wal_compression, max_wal_size (9.5+) /
> checkpoint_segments (< 9.5), checkpoint_timeout and wal_buffers?
xdb301e/postgres M # SELECT name, current_setting(name) FROM pg_settings
WHERE name IN ('max_wal_size', 'checkpoint_timeout', 'wal_compression',
'wal_buffers');
name | current_setting
--------------------+-----------------
checkpoint_timeout | 1h
max_wal_size | 128GB
wal_buffers | 16MB
wal_compression | on
(4 rows)
Time: 0.938 ms
xdb301e/postgres M #
> - Could you quickly describe your workload?
OLTP workload with 80% reads and 20% writes.
>
> Feel free to add any information you think is pertinent ;)
Well, we actually workarounded issues with WAL write rate by increasing
checkpoint_timeout to maximum possible (in 9.6 it can be even more). The
downside of this change is recovery time. Thanks postgres for its stability but
sometimes you can waste ~ 10 minutes just to restart postgres for upgrading to
new minor version and that’s not really cool.
>
> Greetings,
>
> Andres Freund
>
>
> --
> Sent via pgsql-performance mailing list ([email protected])
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
