From 02cfa5e538dd956366555f74c1a20cc63f7e012f Mon Sep 17 00:00:00 2001 From: Souvik Sarkar Date: Wed, 27 Nov 2024 16:03:56 +0530 Subject: [PATCH 1/4] note on vmeff clarification --- xml/utilities.xml | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/xml/utilities.xml b/xml/utilities.xml index 53a04c4980..ddb400be71 100644 --- a/xml/utilities.xml +++ b/xml/utilities.xml @@ -479,6 +479,32 @@ Average: 92.08 211.70 1097.30 0.26 12010.28 0.00 0.00 0 page swapped out is being reused) or 0 (no pages have been scanned). The value should not drop below 30. + + Understanding and addressing %vmeff values exceeding 100% in modern Linux + kernels + + A %vmeff value exceeding 100% means that the number of pages reclaimed (pgsteal) is reported + as higher than the number of pages scanned (pgscank) during memory reclamation. This is + unexpected because under normal circumstances, the kernel should not reclaim more pages than it scans. + + + In modern Linux kernels (5.x and higher), changes in memory management and page reclamation + accounting makes %vmeff less reliable as a measure of virtual memory efficiency. These + changes include separating background and direct reclaim metrics, tracking memory operations + with greater granularity, introducing deferred reclamation, and adding support for NUMA-aware + and cgroup-based memory management. Such updates can cause tools like sar + to misinterpret metrics like pgsteal and pgscank, resulting in %vmeff value + exceeding 100% in certain situatiions. + + + If %vmeff exceeds 100%, avoid using it as a performance indicator. Instead, analyze memory + performance by monitoring pgpgin/s and pgpgout/s for paging activity, majflt/s and fault/s + for page faults, and memory utilization details in /proc/meminfo (for + exmaple, Active, Inactive, Dirty and Writeback). Additionally, correlate these metrics with + application-level performance and I/O patterns to identify potential memory bottlenecks or + inefficiencies. + + Block device statistics report: <command>sar</command> <option>-d</option> From 44e08e79ccfb32202e9ae12e5042b7e4d31a9743 Mon Sep 17 00:00:00 2001 From: Souvik Sarkar Date: Wed, 27 Nov 2024 17:42:57 +0530 Subject: [PATCH 2/4] Editorial fixes as per Daria's suggestion --- xml/utilities.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/xml/utilities.xml b/xml/utilities.xml index ddb400be71..66d8705257 100644 --- a/xml/utilities.xml +++ b/xml/utilities.xml @@ -489,12 +489,12 @@ Average: 92.08 211.70 1097.30 0.26 12010.28 0.00 0.00 0 In modern Linux kernels (5.x and higher), changes in memory management and page reclamation - accounting makes %vmeff less reliable as a measure of virtual memory efficiency. These + accounting make %vmeff less reliable as a measure of virtual memory efficiency. These changes include separating background and direct reclaim metrics, tracking memory operations with greater granularity, introducing deferred reclamation, and adding support for NUMA-aware and cgroup-based memory management. Such updates can cause tools like sar to misinterpret metrics like pgsteal and pgscank, resulting in %vmeff value - exceeding 100% in certain situatiions. + exceeding 100% in certain situations. If %vmeff exceeds 100%, avoid using it as a performance indicator. Instead, analyze memory From b254b2335a40e2c5d33bba33fbaa73d8db3f07bf Mon Sep 17 00:00:00 2001 From: Souvik Sarkar Date: Thu, 28 Nov 2024 12:24:52 +0530 Subject: [PATCH 3/4] Minor typo fix --- xml/utilities.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/xml/utilities.xml b/xml/utilities.xml index 66d8705257..d885aea5f9 100644 --- a/xml/utilities.xml +++ b/xml/utilities.xml @@ -500,7 +500,7 @@ Average: 92.08 211.70 1097.30 0.26 12010.28 0.00 0.00 0 If %vmeff exceeds 100%, avoid using it as a performance indicator. Instead, analyze memory performance by monitoring pgpgin/s and pgpgout/s for paging activity, majflt/s and fault/s for page faults, and memory utilization details in /proc/meminfo (for - exmaple, Active, Inactive, Dirty and Writeback). Additionally, correlate these metrics with + example, Active, Inactive, Dirty and Writeback). Additionally, correlate these metrics with application-level performance and I/O patterns to identify potential memory bottlenecks or inefficiencies. From 0f8408e08409836aad56e62597e06d945f6dc683 Mon Sep 17 00:00:00 2001 From: Souvik Sarkar Date: Mon, 2 Dec 2024 15:47:34 +0530 Subject: [PATCH 4/4] Modified content based on Tanja's feedback --- xml/utilities.xml | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/xml/utilities.xml b/xml/utilities.xml index d885aea5f9..d00ae68998 100644 --- a/xml/utilities.xml +++ b/xml/utilities.xml @@ -480,27 +480,27 @@ Average: 92.08 211.70 1097.30 0.26 12010.28 0.00 0.00 0 The value should not drop below 30. - Understanding and addressing %vmeff values exceeding 100% in modern Linux + <title>Understanding and addressing <guimenu>%vmeff</guimenu> values exceeding 100% in modern Linux kernels - A %vmeff value exceeding 100% means that the number of pages reclaimed (pgsteal) is reported - as higher than the number of pages scanned (pgscank) during memory reclamation. This is + A %vmeff value exceeding 100% means that the number of pages reclaimed (pgsteal) is reported + as higher than the number of pages scanned (pgscank) during memory reclamation. This is unexpected because under normal circumstances, the kernel should not reclaim more pages than it scans. In modern Linux kernels (5.x and higher), changes in memory management and page reclamation - accounting make %vmeff less reliable as a measure of virtual memory efficiency. These + accounting make %vmeff less reliable as a measure of virtual memory efficiency. These changes include separating background and direct reclaim metrics, tracking memory operations with greater granularity, introducing deferred reclamation, and adding support for NUMA-aware and cgroup-based memory management. Such updates can cause tools like sar - to misinterpret metrics like pgsteal and pgscank, resulting in %vmeff value + to misinterpret metrics like pgsteal and pgscank, resulting in %vmeff value exceeding 100% in certain situations. - If %vmeff exceeds 100%, avoid using it as a performance indicator. Instead, analyze memory - performance by monitoring pgpgin/s and pgpgout/s for paging activity, majflt/s and fault/s + If %vmeff exceeds 100%, avoid using it as a performance indicator. Instead, analyze memory + performance by monitoring pgpgin/s and pgpgout/s for paging activity, majflt/s and fault/s for page faults, and memory utilization details in /proc/meminfo (for - example, Active, Inactive, Dirty and Writeback). Additionally, correlate these metrics with + example, Active, Inactive, Dirty and Writeback). Additionally, correlate these metrics with application-level performance and I/O patterns to identify potential memory bottlenecks or inefficiencies.