現在、システムのRAMが非常に簡単に不足しているため、OOM Killerを実行しているように見えるLinuxボックスに問題があります。一方、通常は同様の負荷をかなりうまく処理します。確認してみるとRAMが多く消費されているfree -tmことがわかりました。buff/cache通常、ディスクIOをキャッシュしたいので大丈夫ですが、今はシステムにメモリが足りなくてもカーネルはそのメモリを解放できないようです。
現在のシステムは次のとおりです。
total used free shared buff/cache available
Mem: 31807 15550 1053 14361 15203 1707
Swap: 993 993 0
Total: 32801 16543 1053
ただし、キャッシュを強制的に解放しようとすると、次の結果が表示されます。
$ grep -E "^MemTotal|^Cached|^Committed_AS" /proc/meminfo
MemTotal: 32570668 kB
Cached: 15257208 kB
Committed_AS: 47130080 kB
$ time sync
real 0m0.770s
user 0m0.000s
sys 0m0.002s
$ time echo 3 | sudo tee /proc/sys/vm/drop_caches
3
real 0m3.587s
user 0m0.008s
sys 0m0.680s
$ grep -E "^MemTotal|^Cached|^Committed_AS" /proc/meminfo
MemTotal: 32570668 kB
Cached: 15086932 kB
Committed_AS: 47130052 kB
これにより、すべてのダーティページがディスクに書き込まれ、すべてのキャッシュが削除されると、15 GBのキャッシュのうち約130 MBしか確保されません。ご覧のとおり、私はすでにかなり多くのオーバーコミットを実行しているため、機能していないキャッシュに15 GBのRAMを無駄にすることはできません。
カーネルはslabtopまた、600MB未満のスペースを使用すると主張しています。
$ sudo slabtop -sc -o | head
Active / Total Objects (% used) : 1825203 / 2131873 (85.6%)
Active / Total Slabs (% used) : 57745 / 57745 (100.0%)
Active / Total Caches (% used) : 112 / 172 (65.1%)
Active / Total Size (% used) : 421975.55K / 575762.55K (73.3%)
Minimum / Average / Maximum Object : 0.01K / 0.27K / 16.69K
OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME
247219 94755 0% 0.57K 8836 28 141376K radix_tree_node
118864 118494 0% 0.69K 5168 23 82688K xfrm_state
133112 125733 0% 0.56K 4754 28 76064K ecryptfs_key_record_cache
$ cat /proc/version_signature
Ubuntu 5.4.0-80.90~18.04.1-lowlatency 5.4.124
$ cat /proc/meminfo
MemTotal: 32570668 kB
MemFree: 1009224 kB
MemAvailable: 0 kB
Buffers: 36816 kB
Cached: 15151936 kB
SwapCached: 760 kB
Active: 13647104 kB
Inactive: 15189688 kB
Active(anon): 13472248 kB
Inactive(anon): 14889144 kB
Active(file): 174856 kB
Inactive(file): 300544 kB
Unevictable: 117868 kB
Mlocked: 26420 kB
SwapTotal: 1017824 kB
SwapFree: 696 kB
Dirty: 200 kB
Writeback: 0 kB
AnonPages: 13765260 kB
Mapped: 879960 kB
Shmem: 14707664 kB
KReclaimable: 263184 kB
Slab: 601400 kB
SReclaimable: 263184 kB
SUnreclaim: 338216 kB
KernelStack: 34200 kB
PageTables: 198116 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 17303156 kB
Committed_AS: 47106156 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 67036 kB
VmallocChunk: 0 kB
Percpu: 1840 kB
HardwareCorrupted: 0 kB
AnonHugePages: 122880 kB
ShmemHugePages: 0 kB
ShmemPmdMapped: 0 kB
FileHugePages: 0 kB
FilePmdMapped: 0 kB
CmaTotal: 0 kB
CmaFree: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
Hugetlb: 0 kB
DirectMap4k: 9838288 kB
DirectMap2M: 23394304 kB
CachedシステムRAMの約50％を占め、/proc/meminfoそれを解放できない原因を説明できますか？shared_buffers巨大なページがアクティブなPostgreSQLが表示されることを知っていますが、このコンピュータCachedではPostgreSQLを実行していません。疑わしいほど大きいようですが、Shmemどのmeminfoプロセスがそれを使用しているのかどうかを知ることができますか？
私はこれが誤動作するプログラムかもしれないと推測します。しかし、どのプロセスがそのRAMを占有しているかを調べるためにシステムに問い合わせるにはどうすればよいですか？現在452個のプロセス/2144個のスレッドがあるため、これをすべて手動で調べるのは難しい作業です。
また、このRAM使用の理由がSystem V共有メモリのためではないことも確認しました。
$ ipcs -m | awk 'BEGIN{ sum=0 } { sum += $5 } END{print sum}'
1137593612
報告される合計バイト数ipcsは大きいが、依然として「ただ」1.1GBである。
同様の問題も発見しましたhttps://askubuntu.com/questions/762717/high-shmem-memory-usageShmemの高い使用量は、tmpfsマウントされたディレクトリのゴミによって引き起こされます。しかし、これは私のシステムでも問題にならないようです。 221MBのみが使用されます。
$ df -h -B1M | grep tmpfs
tmpfs 3181 3 3179 1% /run
tmpfs 15904 215 15689 2% /dev/shm
tmpfs 5 1 5 1% /run/lock
tmpfs 15904 0 15904 0% /sys/fs/cgroup
tmpfs 3181 1 3181 1% /run/user/1000
tmpfs 3181 1 3181 1% /run/user/1001
tmpfs削除されたがファイルハンドルがまだ存在するシステムに存在していたファイルが出力dfに表示されないが、まだRAMを占有していることを説明する別の答えが見つかりました。 Google Chromeが閉じることを忘れた（？）ファイルを削除するのに約1.6GBが無駄になることがわかりました。
$ sudo lsof -n | grep "/dev/shm" | grep deleted | grep -o 'REG.*' | awk 'BEGIN{sum=0}{sum+=$3}END{print sum}'
1667847810
（はい、上記のフィルタリングはありませんが、フィルタリングもテストしましたが、chromeGoogle Chromeが開いたファイルハンドルを持つファイルを削除してRAMを無駄にするのとほぼ同じです。）
修正する:Shmem: 14707664 kB実際の犯人は削除されたファイルで記述される1.6GB tmpfs、System V共有メモリで説明される1.1GB、tmpfs既存のファイルが約220MBのように見える。だから、まだどこかに約11.8GBのスペースがありません。
少なくともLinuxカーネル5.4.124では、Cachedこれはすべて含まれているようですが、キャッシュが解放されてもそのフィールドをゼロにすることはできませんShmem。echo 3 > drop_cachesCached
もしそうなら、実際の質問はShmem予想しませんが、なぜRAMが10GB以上を占めるのかということです。
修正する:確認の結果、（「RES Anonymous」）および（「RES Shared」）topフィールドがEclipseを指していることがわかりました。 Thunderbirdを閉じてもキャッシュメモリは解放されませんが、Eclipseを閉じると3.9GBが解放されます。 JVMフラグを使用してEclipseを実行しているので、JVMのメモリ使用量はまだ！と表示されることがあります。プロセスをランダムに終了し、メモリが解放されたことを確認する代わりに、メモリ使用量をプロセスメソッドにマッピングします。RSanRSshthunderbirdCached-Xmx4000mCached
修正する:tmpfs背後で使用されるファイルシステムもShmem増加に寄与することができる。これが私がテストした方法です：
$ df --output=used,source,fstype -B1M | grep -v '/dev/sd' | grep -v ecryptfs | tail -n +2 | awk 'BEGIN{sum=0}{sum+=$1}END{print sum}'
4664
したがって、実際のブロックデバイスがサポートするファイルシステムのみを除外しても（私もecryptfsこのブロックデバイスにマウントされています）、約4.7 GBのメモリ損失しか説明できません。そのうち4.3GBは、私が知っている限り、作成されたが未使用のsnapdインストールsquashfsに対応していますShmem。
修正する:場合によっては、GPUドライバが保持するGEMオブジェクトとして記述されます。これを照会する標準インターフェイスはないようですが、Intel統合グラフィックスでは次のような結果が得られます。
$ sudo sh -c 'cat /sys/kernel/debug/dri/*/i915_gem_objects' | perl -npe 's#([0-9]+) bytes#sprintf("%.1f", $1/1024/1024)." MB"#e'
1166 shrinkable [0 free] objects, 776.8 MB
Xorg: 114144 objects, 815.9 MB (38268928 active, 166658048 inactive, 537980928 unbound, 0 closed)
calibre-paralle: 1 objects, 0.0 MB (0 active, 0 inactive, 32768 unbound, 0 closed)
Xorg: 595 objects, 1329.9 MB (0 active, 19566592 inactive, 1360146432 unbound, 0 closed)
chrome: 174 objects, 63.2 MB (0 active, 0 inactive, 66322432 unbound, 0 closed)
chrome: 174 objects, 63.2 MB (0 active, 0 inactive, 66322432 unbound, 0 closed)
chrome: 20 objects, 1.2 MB (0 active, 0 inactive, 1241088 unbound, 0 closed)
firefox: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
GLXVsyncThread: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
chrome: 1100 objects, 635.1 MB (0 active, 0 inactive, 180224 unbound, 0 closed)
chrome: 1100 objects, 635.1 MB (0 active, 665772032 inactive, 180224 unbound, 0 closed)
chrome: 20 objects, 1.2 MB (0 active, 0 inactive, 1241088 unbound, 0 closed)
[k]contexts: 3 objects, 0.0 MB (0 active, 40960 inactive, 0 unbound, 0 closed)
この結果は私には理解できません。各行が物理メモリ割り当てであれば、合計は数百ギガバイトになります！
GPUドライバが特定の行を複数回報告していると仮定しても、次のような結果が得られます。
$ sudo sh -c 'cat /sys/kernel/debug/dri/*/i915_gem_objects' | sort | uniq | perl -npe 's#([0-9]+) bytes#sprintf("%.1f", $1/1024/1024)." MB"#e'
1218 shrinkable [0 free] objects, 797.6 MB
calibre-paralle: 1 objects, 0.0 MB (0 active, 0 inactive, 32768 unbound, 0 closed)
chrome: 1134 objects, 645.0 MB (0 active, 0 inactive, 163840 unbound, 0 closed)
chrome: 1134 objects, 645.0 MB (0 active, 676122624 inactive, 163840 unbound, 0 closed)
chrome: 174 objects, 63.2 MB (0 active, 0 inactive, 66322432 unbound, 0 closed)
chrome: 20 objects, 1.2 MB (0 active, 0 inactive, 1241088 unbound, 0 closed)
firefox: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
GLXVsyncThread: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
[k]contexts: 2 objects, 0.0 MB (0 active, 24576 inactive, 0 unbound, 0 closed)
Renderer: 4844 objects, 7994.5 MB (0 active, 0 inactive, 8382816256 unbound, 0 closed)
Xorg: 114162 objects, 826.8 MB (0 active, 216350720 inactive, 537980928 unbound, 0 closed)
Xorg: 594 objects, 1329.8 MB (14794752 active, 4739072 inactive, 1360146432 unbound, 0 closed)
これは、4〜8 GBの範囲で予想される合計よりもはるかに多くの数値です。 （現在のシステムにはログインシートが2つあるので、Xorgプロセスを2つ見たいと思います。）
修正する:GPUデバッグ出力をさらに詳しく見ると、このunbound数字はRAMの仮想ブロックが実際には使用されていないことを意味すると信じています。これにより、より合理的なGPUメモリ使用量の数値を得ることができます。
$ sudo sh -c 'cat /sys/kernel/debug/dri/*/i915_gem_objects' | perl -npe 's#^(.*?): .*?([0-9]+) bytes.*?([0-9]+) unbound.*#sprintf("%s: %.1f", $1, ($2-$3)/1024/1024)." MB"#eg' | grep -v '0.0 MB'
1292 shrinkable [0 free] objects, 848957440 bytes
Xorg: 303.1 MB
Xorg: 32.7 MB
chrome: 667.5 MB
chrome: 667.5 MB
これは約1.5 GBのRAMを説明していますが、これは私が作業しているデータに対して正常であるようです。まだどこかにいくつかのギガバイトが足りません！
修正する:現在の問題は、実際にRAMがサポートしている削除されたファイルが原因であると思います。これは、ファイルを削除/破棄した後に開かれたファイルハンドルが漏洩する破損したソフトウェアによって引き起こされる可能性があります。私が走るとき
$ sudo lsof -n | grep -Ev ' /home/| /tmp/| /lib/| /usr/' | grep deleted | grep -o " REG .*" | awk 'BEGIN{sum=0}{sum+=$3}END{print sum / 1024 / 1024 " MB"}'
4560.65 MB
（手動で収集されたパスプレフィックスのリストは実際には実際のブロックデバイスによってサポートされています。私のルートは実際のブロックデバイスでサポートされているため、ここにすべてのブロックマウントポイントを一覧表示することはできません。非マウントポイントディレクトリを一覧表示し、ここより長いブロックインストールをすべて一覧表示します/.)
これは、ほぼ4.6GBのRAM損失を説明します。出力ipcs、GPU RAM（バインドされていないメモリ仮定）、tmpfs使用量を組み合わせると、現在どこかで約4GBがありませんShmem！
ベストアンサー1
私は上記の質問の著者です。まだ完全な答えはありませんが、これが最も有名な説明です。
最新のLinuxカーネルでは、
Cachedこの値は/proc/meminfoディスクキャッシュの量を説明しません。しかし、カーネル開発者は現在、この設定を変更するには遅すぎると思います。。実際に使用されるディスクキャッシュの量を実際に測定するには、
Cached - Shmemそれを推定する計算を実行する必要があります。元の質問から数字を取ると15151936−14707664（kiB）（from/proc/meminfo）または（kiB）の出力が得られるため、444272システムに実際に約433MiBのディスクキャッシュがあるようです。この場合、すべてのディスクキャッシュを削除しても大量のメモリが確保されるわけではありません。すべてのディスクキャッシュを削除しても、フィールドはCached3％だけ減少します。
したがって、最良の推測は、一部のユーザーモードソフトウェアは、多くの共有メモリ（通常tmpfsまたは共有メモリマッピング）を使用して、Cachedシステムに実際にディスクキャッシュがほとんどないにもかかわらず高い値を示すことです。メモリ不足の状態が近づいています。Committed_AS私はこれがこの理論を支えるのに大きな助けになると思いますMemTotal。
linux-mm以下は、上記のリンクが後で機能しない場合に備えて、上記のリンクされたスレッドの結論の（短縮された）コピーです。
タイトル：Re：Shmemが/ proc / meminfoのキャッシュに含まれているのはなぜですか？
送信者： Vlastimil Babka @ 2021-08-30 16:05 UTC21年8月30日午前12時44分に、Mikko Rantalainenは次のように書きました。
これは fs/proc/meminfo.c 関数 meminfo_proc_show() からすぐにはわかりませんが、 Cached: フィールドの出力には常にすべての Shmem: フィールドが含まれているようです。
だが今変えればより大きな混乱を引き起こすことができる。人々はもはや新しいカーネルの出力を最初に見ると誤解しません（IIRCの「free」コマンドもそれを使用します）。しかし、古いカーネルと新しいカーネルを使用している人は、それがある時点で変更されたことを考慮する必要があります...悪いです。
送信者: ハリド・アジズ @ 2021-08-30 19:38 UTC
2021年8月30日月曜日20:26 +0300に、Mikko Rantalainenは次のように書きました。
もちろん、1つの可能な解決策は、「キャッシュ済み」を変更せずに実際のキャッシュセマンティクスに「キャッシュ」を導入することです（つまり、（キャッシュ済み - Shmem）とメモリ対応RAMの合計を含む）。これにより、システム管理者は一意の値を持つ2つ以上の異なるフィールドを表示して文書を見つけることができます。
新しいフィールドを追加することをお勧めします。 / proc / meminfoのデータを解釈し、そのデータに対して操作を実行するためのツール/スクリプトがたくさんあるかもしれません。既存のデータの意味を変更すると、これらのツールは機能しません。新しい分野の欠点は、出力がさらに拡張されるが、既存のツールを損傷しないことです。