Eu atualizei recentemente uma máquina virtual de 12 GB para 64 GB e descobri que sem nenhum aplicativo em execução, metade da memória foi alocada. Desde o upgrade, a carga da VM é caótica e, na maioria das vezes, a VM não responde.
Não consegui encontrar htop , nem ps , processo que alocava essa memória, mas descobri na df -h de saída que algumas partições, como /tmp , /sys/fs/cgroup , /run e /dev/shm estavam usando 32G do sistema de arquivos tmpfs e /dev usando 32 GB de devtmpfs .
Eu entendo que essa memória é compartilhada e que essa é a causa do uso de memória e que novos aplicativos podem usar a memória ocupada por essas partições. Por favor me corrija se eu estiver errado. No entanto, o comando free -mh reporta cerca de 20 GB de memória disponível para novos aplicativos. O mesmo para a coluna "livre".
A df -h de saída.
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
...
A free -mh de saída.
total used free shared buff/cache available
Mem: 62G 41G 21G 24M 106M 21G
A partir do px aux , o programa que usou mais memória foi de 75 MB de /usr/lib/systemd/systemd-journald . Eu não tenho a saída desse momento, nem dos comandos vmstat e top -b 1 .
Em outra máquina Cento com 128GB, notei que tmpfs usa 64GB, mas, ainda assim, a coluna "disponível" da saída free -mh indica que novas aplicações podem alocar até 123GB, mesmo que haja 59GB livre de acordo com a coluna "livre".
Este último exemplo parece correto e compreensível. Mas não consigo entender o primeiro.
Estou tendo problemas para atribuir mais de 12 GB de memória a um aplicativo java ( ES_HEAP_SIZE=12g ) e gostaria de saber se há algo que eu deva considerar para melhorar o comportamento da memória. Além disso, gostaria de entender melhor as razões por trás dessa partição tmpfs e por que ela aloca metade da memória do sistema. Existe alguma maneira de reduzir o tamanho de devtmpfs e tmpfs ? E como isso afeta o sistema?
O sistema é um Centos 7.1.1503 com a versão do kernel 3.10.0-229.el7.x86_64 .
Muito obrigado antecipadamente.
Postscript : O aplicativo java trava de uma forma que eu não consigo nem fazer ps ou htop e a única solução é fazer killall -9 java . O sistema também começa a não responder bem.
atualização de 2017/01/11
Agora, mais processos estão em execução, já que mais aplicativos são executados.
A saída lsof -n | grep deleted estava vazia.
Eu fiz ps aux | awk '{print $6/1024 " MB\t\t" $11}' | sort -n que informa:
- 143 processos com menos de 1 MB.
- 55 processos entre 1 e 10MB que somam 221MB.
- Apenas 5 processos acima de 10 MB, que são:
- python com 14,89 MB
- rsyslogd com 26 MB
- systemd-journald com 47,83 MB
- kibana com 78,72 MB
- java com 13456 MB
Ainda assim, o comando free -mh relata o seguinte e não sei onde o restante da memória foi consumido.
total used free shared buff/cache available
Mem: 62G 54G 5.5G 478M 3.2G 7.8G
Atualização de 16/01/2017
O problema já está resolvido. Primeiro, havia questões diferentes nesta questão.
O uso de memória não estava relacionado ao tmpfs ou ao devtmpfs , mas com o aumento de memória do host vmware. Isso, junto com uma cota de 8 GB (que contradiz a atribuição de memória à VM) resultou no comportamento estranho relatado em que a carga da VM era caótica. Houve erros no dmesg mencionando vmballoon_work .
Não encontrei nenhuma informação sobre esse problema que sugerisse que poderia ser um problema do host, por isso acho que essa pergunta / resposta pode ser útil para problemas futuros. O ponto chave são essas mensagens do 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
Eu quero agradecer a Rui F Ribeiro por sua resposta sobre o tmpfs e% código%. Mudei o título de Por que o CentOS usa metade da memória para devtmpfs ou tmpfs? para Onde está meu CentOS
Máquina Virtual usando metade da memória? e adicionou algumas tags.