Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Additional clarification about %vmeff exceeding 100% in newer kernels #1782

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
+26 −0
Open

Additional clarification about %vmeff exceeding 100% in newer kernels #1782

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
ae20a40
note on vmeff clarification
sounix000 Nov 27, 2024
1a8f511
Editorial fixes as per Daria's suggestion
sounix000 Nov 27, 2024
8e9af4a
Minor typo fix
sounix000 Nov 28, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 26 additions & 0 deletions xml/utilities.xml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
</para>
<note>
<title>Understanding and addressing %vmeff values exceeding 100% in modern Linux
kernels</title>
<para>
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.
</para>
<para>
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
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 <command>sar</command>
to misinterpret metrics like pgsteal and pgscank, resulting in %vmeff value
exceeding 100% in certain situations.
</para>
<para>
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 <filename>/proc/meminfo</filename> (for
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.
</para>
</note>
</sect4>
<sect4 xml:id="sec-util-multi-sar-report-disk">
<title>Block device statistics report: <command>sar</command> <option>-d</option></title>
Expand Down