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 | 1baa1406-00ef-4d49-b28f-e9ec631a2ac6@oss.nttdata.com обсуждение исходный текст |
Ответ на | Don't keep closed WAL segment in page cache after replay (Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>) |
Ответы |
Re: Don't keep closed WAL segment in page cache after replay
|
Список | pgsql-hackers |
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? > This patch adds a POSIX_FADV_DONTNEED before closing a WAL segment, > immediately releasing cached pages. Maybe we should do this only on a standby where WAL archiving isn't working and it isn't acting as a sender or publisher. Regards, -- Fujii Masao NTT DATA Japan Corporation
В списке pgsql-hackers по дате отправления: