這篇文章主要講解了“為什么PostgreSQL checkpointer后臺進程使用這么多內存”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“為什么PostgreSQL checkpointer后臺進程使用這么多內存”吧！
本節內容來源于PGer的一個問題:
Q:
為什么checkpointer后臺進程使用這么多內存?
[pg12@localhost ~]$ ps -aux|grep postgres pg12 1506 0.0 1.8 753156 34704 ? Ss 10:30 0:00 /appdb/xdb/pg12beta1/bin/postgres pg12 1507 0.0 0.0 187304 1472 ? Ss 10:30 0:00 postgres: logger pg12 1509 0.0 24.1 754120 452672 ? Ss 10:30 0:04 postgres: checkpointer pg12 1510 0.0 28.4 753292 533184 ? Ss 10:30 0:08 postgres: background writer pg12 1511 0.0 0.9 753260 18012 ? Ss 10:30 0:11 postgres: walwriter pg12 1513 0.0 0.0 189420 1448 ? Ss 10:30 0:00 postgres: archiver last was 00000001000000020000005C pg12 1514 0.0 0.0 189556 1324 ? Ss 10:30 0:00 postgres: stats collector pg12 1515 0.0 0.1 753688 1984 ? Ss 10:30 0:00 postgres: logical replication launcher pg12 2281 0.0 0.0 112660 972 pts/3 S+ 16:38 0:00 grep --color=auto postgres [pg12@localhost ~]$ grep 'shared' $PGDATA/postgresql.conf shared_buffers = 512MB # min 128kB #shared_memory_type = mmap # the default is the first option dynamic_shared_memory_type = posix # the default is the first option #wal_buffers = -1 # min 32kB, -1 sets based on shared_buffers #shared_preload_libraries = '' # (change requires restart)
比如上例,共享內存設置為512MB,在2G內存的機器上,checkpointer和background writer進程占用了差不多25%的內存大小.
A:
resident” RAM of a postgres subprocess is often just be the fraction of shared_buffers it’s read/written. checkpointer must necessarily read all dirty pages from s-b and write out to disk (by way of page cache), so that’s why its RSS is nearly 32GB. And the recovery process is continuously writing into s-b.
原因是checkpointer和bg writer需要從shared memory中讀取數據(從s-b到page cache)并刷到磁盤上,因此給人占用大量內存的假象.
感謝各位的閱讀，以上就是“為什么PostgreSQL checkpointer后臺進程使用這么多內存”的內容了，經過本文的學習后，相信大家對為什么PostgreSQL checkpointer后臺進程使用這么多內存這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
