Re: Don't keep closed WAL segment in page cache after replay
От | Fujii Masao |
---|---|
Тема | Re: Don't keep closed WAL segment in page cache after replay |
Дата | |
Msg-id | 22c1e824-c378-4de8-9977-b1fca87d92b7@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: Don't keep closed WAL segment in page cache after replay (Fujii Masao <masao.fujii@oss.nttdata.com>) |
Список | pgsql-hackers |
On 2025/07/02 22:24, Fujii Masao wrote: > > > On 2025/07/02 19:10, Anthonin Bonnefoy wrote: >> Hi, >> >> I've been looking at page cache usage as some of our replicas were >> under memory pressure (no inactive pages available) which led to WAL >> replay lag as the recovery process had to read from disk. One thing >> I've noticed was that the last WAL files are in the pagecache even >> after having been replayed. >> >> This can be checked with vmtouch: >> vmtouch pg_wal/* >> Files: 141 >> Directories: 2 >> Resident Pages: 290816/290816 1G/1G 100% >> >> And page-types shows a replayed WAL file in the active LRU: >> page-types -Cl -f 000000010000001B00000076 >> page-count MB long-symbolic-flags >> 4096 16 referenced,uptodate,lru,active >> >> From my understanding, once replayed on a replica, WAL segment files >> won't be re-read. So keeping it in the pagecache seems like an >> unnecessary strain on the memory (more so that they appear to be in >> the active LRU). > > WAL files that have already been replayed can still be read again > for WAL archiving (if archive_mode = always) or for replication > (if the standby is acting as a streaming replication sender or > a logical replication publisher). No? Also, the WAL summarizer might read those WAL files as well. Regards, -- Fujii Masao NTT DATA Japan Corporation
В списке pgsql-hackers по дате отправления: