CentOSがdevtmpfsまたはtmpfsにメモリの半分を使用するのはなぜですか?

CentOSがdevtmpfsまたはtmpfsにメモリの半分を使用するのはなぜですか?

最近、仮想マシンを12 GBから64 GBにアップグレードしましたが、どのアプリケーションも実行されず、メモリの半分が割り当てられていることがわかりました。アップグレード後、仮想マシンの負荷が混乱し、ほとんどの場合、仮想マシンが応答しなくなります。

htopどちらのプロセスがこのメモリを両方に割り当てているかが見つかりませんでしたが、出力の一部のpsパーティションdf -h(たとえば/tmp、、および。/sys/fs/cgroup/run/dev/shmtmpfs/devdevtmpfs

私はこのメモリが共有されることを理解しています。これがメモリが使用される理由であり、新しいアプリケーションがこれらのパーティションが占めるメモリを使用できることです。間違っていたら訂正してください。ただし、このfree -mhコマンドは新しいアプリケーションに約20 GBのメモリを使用できることを報告します。 「無料」列も同様です。

出力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 aux75MBです/usr/lib/systemd/systemd-journald。その瞬間の出力やvmstatandコマンドの出力はありませんtop -b 1

他の128GB Centosシステムでは、64GBが使用されていることを確認しました。ただし、「Free」列によれば、59GBの空き容量があるにもかかわらず、出力のtmpfs「Free」列には、新しいアプリケーションが最大123GBまで割り当てることができることがまだ示されています。free -mh

後者の例は正確で理解しやすいようです。しかし、私は前者を理解できません。

Javaアプリケーション()に12 GB以上のメモリを割り当てるのに問題があり、ES_HEAP_SIZE=12gメモリの動作を改善するためにどのような措置を講じるべきか疑問に思います。また、tmpfsこのパーティションの理由とシステムメモリの半分を割り当てる理由をよりよく理解したいと思います。devtmpfs合計のサイズを減らす方法はありますかtmpfs?システムにどのような影響がありますか?

このシステムはCentos 7.1.1503カーネルバージョンです3.10.0-229.el7.x86_64。よろしくお願いします。

PS: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

  • 1MB未満のプロセスが143個あります。
  • 55プロセスのサイズは1MBから10MBまでで、合計221MBです。
  • 10MBを超えるプロセスは5つだけです。
    • Python 14.89MB
    • rsyslogd 26MB
    • systemd-ジャーナルド 47.83MB
    • キバナ 78.72MB
    • Java 13456MB

ただし、free -mhコマンドは次のことを報告し、残りのメモリがどこで消費されているかはまったくわかりません。

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

2017年1月16日更新

問題が解決しました。まず、この問題にはいくつかの問題があります。

tmpfsdevtmpfsメモリ使用量は、vmwareホストのメモリ拡張とは関係ありません。これは、8 GB クォータ (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

ありがとうございますレイF.リベイロとに対する彼のtmpfs答えdevtmpfs。タイトルから変更しました。CentOSがdevtmpfsまたはtmpfsにメモリの半分を使用するのはなぜですか?到着CentOS仮想マシンで使用されるメモリの半分はどこにありますか?そして、いくつかのタグを追加しました。

ベストアンサー1

あなたdevtmpfstmpfsファイルシステムは実際にGBのメモリを使用しません。 32GBまで増やすことができますが、これは増やすことができる最大制限です。上限も構成可能で、使用する内容ではなくコンテンツがあるRAM部分だけを占めます。

dfを詳しく見ると
/dev1M未満のメモリを使用しているので、0、
/dev/shm同じもの、
/sys/fs/cgroup同じ状況で表示され、
/tmp17MBが使用中、
/run49MBが使用中です。

したがって、devtmpfs、tmpfsファイルシステムの組み合わせは70MB未満のRAMを使用します。 (メガバイト単位なので参考にしてください)

RAMを消費することは確かにファイルシステムではありません。

私が言ったように、それが面倒な場合は制限値を変更できますが、今はJVMパラメータで使用するように設定されたRAMの量に焦点を当てます。

最後に、OPからのフィードバックによると、vmwareホストにメモリ拡張の問題があり、dmesgでvmballoon_workを参照するとエラーが発生します。

これは、VMハイパーバイザーの8 GBクォータと一緒にVM負荷が歪むという奇妙な動作が報告された結果をもたらし、これらのファイルシステムが犯人ではないことを確認します。

おすすめ記事