Começando 2015, todos se lembram de como foi 2014. Então resolvi escrever com um artigo sobre memória :)
Durante umas das discussões no grupo SOSLinux, alguém postou que já não usava Linux com swap fazia um tempo. Nos meus velhos conceitos Unix adquiridos no século passado isso era algo inconcebível. Uma heresia. Um motivo pra receber um belo dum RTFM.
Esse é o problema de ter "aquela mesma velha opinião formada sobre tudo", como dizia Raul Seixas. As coisas mudam. Os sistemas evoluem. Aquela recomendação de sempre se ter swap, e com fórmulas mágicas sobre seu tamanho, são coisas do passado, de uma era em que Linux era pra servidores e desktops. Agora Linux está em todo lugar. Na minha TV, no meu telefone, no meu tablet, e vai saber mais onde. Talvez já esteja até no meu café e eu ainda não saiba.
Mas o fato é que naquela época a idéia era que as máquinas seriam cada vez maiores, mais potentes, mais gigantes, mais mais, muito mais. Na verdade até são. Mas aconteceu um fato interessante: o cloud. Esse conceito permitiu uma forma de computação mais distribuída, com vários pequenos computadores ao invés de somente um maior. E esse conceito foi se espalhando. Se pensarmos hoje em dia nos celulares, eles são uma extensão computacional de algo que roda num datacenter. Temos uma parte do aplicativo rodando localmente, e outra parte na nuvem.
Nesse novo paradigma, não é preciso tanto swap quanto antes. Meu laptop tem 8 GB de RAM (tinha 12 GB com um pente extra de 4 GB que comprei no Dealextreme, mas o danado teima em dar problema de acesso e travar), mais que suficiente pra muita coisa.
Então resolvi experimentar.
Desabilitei o swap (swapoff /dev/mapper/vg-swap) e comentar a linha que o habilitava durante o boot no /etc/fstab. E funcionou. Mas bastou abrir chrome, firefox, thunderbird e eclipse pra coisa ficar feia (claro que a culpa é do java).
root@elx3030vlm-78:vm# head -16 /proc/meminfo MemTotal: 7926776 kB MemFree: 218640 kB MemAvailable: 889676 kB Buffers: 57568 kB Cached: 750036 kB SwapCached: 0 kB Active: 6672176 kB Inactive: 404504 kB Active(anon): 6282356 kB Inactive(anon): 55548 kB Active(file): 389820 kB Inactive(file): 348956 kB Unevictable: 65852 kB Mlocked: 65852 kB SwapTotal: 0 kB SwapFree: 0 kB
Quando chega próximo do limite de memória, eu simplesmente tenho de aguardar o kernel decidir matar alguma coisa pra eu conseguir mandar um comando. Até fiz um vídeo pra mostrar a situação.
{youtube}ga8lG2xE7wc{/youtube}
Nessas ocasiões a carga do sistema vai às alturas, provavelmente por troca de contexto de processos no kernel, tentando achar memória onde não tem.
Quando isso acontece, uma mudança do ambiente gráfico pro console e um reinicio do mesmo resolve. Mas é chato.
Esses são os load averages que consegui enquanto gerava o vídeo acima:
12:51:51 up 21:12, 6 users, load average: 36.61, 59.21, 75.31 13:01:24 up 21:21, 6 users, load average: 57.21, 51.78, 61.71 13:29:59 up 21:50, 6 users, load average: 110.99, 122.08, 107.70
Então melhor com swap? Não é tanto assim. O sistema evoluiu, mas o problema de gerenciamento de memória é coisa do Linux. Com swap esse tipo de problema também acontece, só demora mais. Eu já tinha visto isso justamente com criação de vídeo no kdenlive. Tinha um bug no melt, possivelmente um memory leak, que ia consumindo toda a memória. Travava? Não, mas tinha de aguardar o kernel matar o melt pra conseguir voltar. Isso levava de 4 a 6 horas. Usando somente RAM acontece o mesmo, mas é mais rápido, por volta de 20 ou 30 minutos.
Eu tentei achar alguma referência de tunning pra ajudar.
Memory Management Approach for Swapless Embedded Systems
http://linux-mm.org/LinuxMMDocumentation
O problema é que a maioria das informações são antigas. No kernel que estou usando, 3.17.7, não tem esses parâmetros. Mas eu tentei melhorar a responsividades alterando algumas coisas:
vm.laptop-mode = 1 vm.memory_failure_early_kill = 1 vm.memory_failure_recovery = 1
O resultado foi bastante satisfatório e agora o sistema tem estado mais responsivo durante alta carga que exige alocação de memória. E com mensagens interessantes vindas do kernel.
Out of memory: Kill process 24223 (chromium-browse) score 332 or sacrifice child Killed process 24223 (chromium-browse) total-vm:1360048kB, anon-rss:242548kB, file-rss:15632kB
Gosto de um sistema que exige sacrifícios.