Memory Monitoring in Linux Systems
In operating systems, virtual memory is organized into pages, each sized at 4KB on x86 architectures. The Linux kernel performs read and write operations on virtual memory in page-sized units. When transferring memory to or from swap space, these operations occur page by page. Managing virtual memory is one of the most intricate components within the Linux kernel.
The term "memory" here encompasses both physical RAM and virtual memory. Virtual memory extends the computer's memory space using disk storage, combining physical RAM and a portion of the hard drive (swap space) into a unified virtual address space. This allows for running more and larger applications, but introduces performance penalties due to slower disk access compared to RAM and additional overhead from swapping between RAM and swap.
Virtual memory is divided into pages, with each page being 4KB on x86 systems. The kernel operates on virtual memory in page-sized chunks, and memory swapping between RAM and swap space also occurs page by page. This process is known as paging. It is important to distinguish paging from swapping; while paging involves moving only parts of a program (pages), swapping refers to moving entire programs to disk, which is largely obsolete in modern systems. Swapping was originally implemented in Unix System V.
Managing virtual memory is complex and could fill an entire book. Here we focus on two key kernel processes relevant to performance monitoring: kswapd and pdflush.
The kswapd daemon monitors pages_high and pages_low thresholds. If available memory drops below pages_low, kswapd begins scanning and attempts to free 32 pages, repeating until available memory exceeds pages_high. During scanning, it evaluates three condisions: 1) Unmodified pages are added to the free list; 2) Modified pages from file systems are flushed to disk; 3) Modified pages not related to file systems are written to swap space.
The pdflush daemon handles synchronization of memory pages related to files, ensuring timely writes to disk. For example, when a file is opened and modified, the kernel does not immediately write changes to disk. Instead, pdflush determines when to flush pages based on the kernel parameter vm.dirty_background_ratio. A setting of 10% means dirty pages will begin flushing to disk once they reach 10% of total memory pages.
# /sbin/sysctl -n vm.dirty_background_ratio
10
vmstat
Continuing with vmstat parameter explanations, the previous article discussed some parameters related to CPU performance. This section covers others. The data below comes from a 256MB RAM, 512MB swap Xen VPS:
# vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 3 252696 2432 268 7148 3604 2368 3608 2372 288 288 0 0 21 78 1
0 2 253484 2216 228 7104 5368 2976 5372 3036 930 519 0 0 0 100 0
0 1 259252 2616 128 6148 19784 18712 19784 18712 3821 1853 0 1 3 95 1
1 2 260008 2188 144 6824 11824 2584 12664 2584 1347 1174 14 0 0 86 0
2 1 262140 2964 128 5852 24912 17304 24952 17304 4737 2341 86 10 0 0 4
- swpd: Amount of swap space currently used, measured in KB;
- free: Available physical memory, measured in KB;
- buff: Size of memory used for buffering I/O operations, measured in KB;
- cache: Size of memory used for caching process address spaces, measured in KB;
- si: Amount of data swapped from disk to RAM, measured in KB;
- so: Amount of data swapped from RAM to disk, measured in KB;
- bi: Number of blocks read from disk to RAM, measured in blocks;
- bo: Number of blocks written from RAM to disk, measured in blocks;
This output represents a system actively swapping. Key observations include:
- Available physical memory (free) shows minimal variation, while swap usage steadily increases, indicating that minimum available memory remains around 2.56MB (10% of 256MB). When dirty pages reach 10%, swap activity begins;
- Buffer size decreases gradually, suggesting the system recognizes low memory and kswapd is reclaiming buffer space;
- kswapd continuously writes dirty pages to swap (so), and increasing swap usage confirms this behavior. According to kswapd's scanning criteria, if a page has been modified but not by the filesystem, it gets written to swap, explaining the continuosu increase in swap usage.