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

When Linux Runs Out of Memory

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.