Memory is very important to databases — much more so than for typical applications (presentation). Unfortunately, because memory allocation is so
complex, it is often hard to figure out how physical RAM is being used. There are several reasons for the complexity:
- Virtual Memory: CPUs in virtual memory mode don’t access RAM directly, but rather through page tables.
- Segmentation: Memory is allocated in specific segments:
text(code), data, and stack.
- Sharing: physical RAM is often shared by multiple processes, either in read-only mode (program instructions), shared mode (read/write of share memory), or copy-on-write (create a new copy on write; used by fork).
Robert Haas’s excellent blog post highlighted much uncertainty about how to analyze memory usage for specific processes, especially Postgres. I commented on his blog, as did others, and now have a much clearer idea of how to study memory usage. A blog post by Chris Siebenmann directly addresses some of my and Robert’s questions, and suggests smem as a way to analyze memory, especially the sharing of memory. It was interesting to learn that smem was designed specifically to address the problems Robert outlined (2007, 2009).Revisiting Memory Reporting