為什麼 CentOS 將一半的記憶體用於 devtmpfs 或 tmpfs？

我最近將一台虛擬機從 12GB 升級到 64GB，發現沒有執行任何應用程序，分配了一半的記憶體。自升級以來，VM 負載很混亂，並且大多數時候 VM 沒有響應。

我也找不到哪個程序正在分配此記憶體htop，ps但我在df -h輸出中發現某些分區（例如/tmp、和）正在使用文件系統中的 32G，/sys/fs/cgroup並使用./run``/dev/shm``tmpfs``/dev``devtmpfs

我知道這塊記憶體是共享的，這就是記憶體使用的原因，新的應用程序可能會使用這些分區佔用的記憶體。如果我錯了，請糾正我。但是，該free -mh命令報告了大約 20GB 的記憶體可用於新應用程序。“免費”列也是如此。

df -h輸出。

Filesystem           Size  Used Avail Use% Mounted on
...
devtmpfs              32G     0   32G   0% /dev
tmpfs                 32G     0   32G   0% /dev/shm
tmpfs                 32G   49M   31G   1% /run
tmpfs                 32G     0   32G   0% /sys/fs/cgroup
tmpfs                 10G   17M   10G   1% /tmp
...

free -mh輸出。

              total        used        free      shared  buff/cache   available
Mem:            62G         41G         21G         24M        106M         21G

px aux使用更多記憶體的程序從/usr/lib/systemd/systemd-journald. 我沒有從那一刻起的輸出，也沒有來自vmstatandtop -b 1命令的輸出。

在另一台 128GB 的​​ Centos 機器上，我注意到tmpfs使用了 64GB，但是free -mh輸出中的“可用”列仍然表明新應用程序最多可以分配 123GB，即使根據“免費”列有 59GB 可用。

後一個例子似乎是正確和可以理解的。但我無法理解前者。

我在將超過 12GB 的記憶體分配給 java 應用程序 ( ES_HEAP_SIZE=12g) 時遇到問題，我想知道是否有什麼我應該考慮改進記憶體行為的。另外，我想更好地理解這個tmpfs分區背後的原因，以及為什麼它分配了一半的系統記憶體。有什麼辦法可以減小devtmpfsand的大小tmpfs？它如何影響系統？

該系統是一個Centos 7.1.1503帶核心的版本3.10.0-229.el7.x86_64。非常感謝您提前。

後記： java 應用程序掛起的方式我什至做不到，ps或者htop唯一的解決方案是做killall -9 java。系統也開始反應遲鈍。

2017/01/11 更新

現在更多的程序正在執行，因為執行了更多的應用程序。lsof -n | grep deleted輸出為空。我做了ps aux | awk '{print $6/1024 " MB\t\t" $11}' | sort -n哪些報告：

• 143 個小於 1MB 的程序。

• 55 個程序在 1 到 10MB 之間，加起來 221MB。

• 只有 5 個超過 10MB 的程序是：

  • python 14.89 MB
  • rsyslogd 26 MB
  • systemd-journald 47.83 MB
  • 78.72 MB 的 kibana
  • java 13456 MB

儘管如此，該free -mh命令仍報告以下內容，我不知道其餘記憶體在哪裡被消耗。

             total        used        free      shared  buff/cache   available
Mem:            62G         54G        5.5G        478M        3.2G        7.8G

2017/01/16 更新

問題已經解決了。首先，這個問題有不同的問題。

tmpfs記憶體使用與或無關，devtmpfs但與 vmware 主機的記憶體膨脹有關。這與 8GB 配額（與分配給 VM 的記憶體相矛盾）一起導致了報告的奇怪行為，即 VM 負載混亂。dmesg 提及時出現錯誤vmballoon_work。

我找不到有關此問題的任何資訊，表明它可能是主機的問題，所以我認為這個問題/答案可能對未來的問題有用。關鍵點是這些 dmesg 消息：

CPU: 6 PID: 10033 Comm: kworker/6:0 Not tainted 3.10.0-229.el7.x86_64 #1
Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 09/17/2015
Workqueue: events_freezable **vmballoon_work** [vmw_balloon]
task: ffff88001d4ead80 ti: ffff880b9bad8000 task.ti: ffff880b9bad8000
RIP: 0010:[<ffffffff812edd71>]  [<ffffffff812edd71>] __list_del_entry+0x31/0xd0
RSP: 0000:ffff880b9badbd68  EFLAGS: 00010246
RAX: ffffffffa032f3c0 RBX: ffffea0000000003 RCX: dead000000200200
RDX: ffffea001107ffe0 RSI: ffff88103fd969f0 RDI: ffffea0011040020
RBP: ffff880b9badbd68 R08: ffffea0011040020 R09: ffff88103fb94000
R10: 0000000000000020 R11: 0000000000000002 R12: ffff88103ff9d0d0
R13: 0000000000000002 R14: ffffff8000000001 R15: 0000000000000002
FS:  0000000000000000(0000) GS:ffff88103fd80000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00000000016ba024 CR3: 0000000267e1c000 CR4: 00000000000407e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Stack:
ffff880b9badbd80 ffffffff812ede1d ffffffffa032f3c0 ffff880b9badbdb0
ffffffffa032d04e ffffffffa032f4c0 ffff880155bd4180 ffff88103fd92ec0
ffff88103fd97300 ffff880b9badbe18 ffffffffa032d388 ffffffffa032f4c8
Call Trace:
[<ffffffff812ede1d>] list_del+0xd/0x30
[<ffffffffa032d04e>] vmballoon_pop+0x4e/0x90 [vmw_balloon]
[<ffffffffa032d388>] vmballoon_work+0xe8/0x720 [vmw_balloon]
[<ffffffff8108f1db>] process_one_work+0x17b/0x470
[<ffffffff8108ffbb>] worker_thread+0x11b/0x400
[<ffffffff8108fea0>] ? rescuer_thread+0x400/0x400
[<ffffffff8109739f>] kthread+0xcf/0xe0
[<ffffffff810972d0>] ? kthread_create_on_node+0x140/0x140
[<ffffffff8161497c>] ret_from_fork+0x7c/0xb0
[<ffffffff810972d0>] ? kthread_create_on_node+0x140/0x140

我要感謝Rui F Ribeiro對tmpfsand的回答devtmpfs。我將標題從**為什麼 CentOS 將一半記憶體用於 devtmpfs 或 tmpfs？我的 CentOS 虛擬機在哪裡使用了一半的記憶體？**並添加了一些標籤。

您devtmpfs和tmpfs文件系統實際上並沒有使用千兆字節的記憶體；它們可能會增長到 32GB，但是這個大小只是它們增長的上限。該上限也是可配置的，而不是他們使用的；他們只吃他們擁有內容的RAM部分。

如果您在 df:

/dev中使用小於 1M 並因此顯示為 0，

/dev/shm則相同的事情，

/sys/fs/cgroup相同的情況，

/tmp使用 17 MB，

/run使用 49 MB。

因此，您組合的 devtmpfs、tmpfs 文件系統使用的 RAM 不到 70MB。（兆字節，請注意）

吃掉你 RAM 的東西肯定不是那些文件系統。

正如我所說，如果這讓您感到困擾，您可以更改它們的上限，但是目前我將關注您的 JVM 參數配置為使用多少 RAM。

最終，根據 OP 的回饋，vmware 主機的記憶體膨脹存在問題，並且 dmesg 中提到 vmballoon_work 時出現錯誤。

這與虛擬機管理程序中的 8GB 配額一起導致了報告的奇怪行為，其中虛擬機負載混亂，因此確實確認這些文件系統不是罪魁禍首。

引用自：https://unix.stackexchange.com/questions/416141