Por que os programas (incluindo o Xorg) fecham quando estão fora da RAM, mas o Swap está quase vazio?

Question

Eu tenho algumas swap configuradas e acredito ativadas ...

Filename                Type        Size    Used    Priority
/dev/sda5                               partition   7811068 1124912 200
/mnt/data02/swapfile                    file        134217724   37032   100
/home/swapfile                          file        134217724   36600   -1

Mas, quando o monitor do sistema mostra a memória atingindo 100%, o sistema tende a responder fechando / travando programas. O Xorg travou dessa maneira, assim como o driver sem fio. Enquanto isso acontece, o monitor do sistema mostra pouco (menos de 5 GiB) do Swap. Confirmei que o swappiness não está configurado para um valor extremo (e as alterações neste parâmetro parecem não ter efeito sobre o problema).

~$  cat /proc/sys/vm/swappiness
70

O sistema tem uma enorme quantidade de RAM ...

~$ free -h
             total       used       free     shared    buffers     cached
Mem:          125G        20G       105G       161M        54M       1.1G
-/+ buffers/cache:        19G       106G
Swap:         263G       1.1G       262G

... mas às vezes eu executo o orçamento em recursos de memória e seria bom se ele falhasse mais do que as coisas quebrando.

O que posso fazer para resolver este problema?

EDITAR

~$ cat /etc/fstab
    # <file system> <mount point>   <type>  <options>       <dump>  <pass>
    # / was on /dev/sda3 during installation
    UUID=8dfbed62-9957-4f06-b4e1-a42020adec91 /               ext4    errors=remount-ro 0       1
    # /home was on /dev/sda6 during installation
    UUID=b6f33408-1d8b-4302-9983-5c778ef64f47 /home           ext4    defaults        0       2
    # swap was on /dev/sda5 during installation
    # ae0304dd-e63e-4d3a-99da-9c9d7a034c6e is the swap file
    UUID=fd4c00c9-49bf-4562-adea-1c817fc57ce9 none            swap    sw,pri=200              0       0
    UUID=3A323DCA323D8BBF /mnt/data01 ntfs-3g defaults,windows_names,locale=en_US.utf8  0 0
    UUID=4cc8a19d-5991-4186-8f65-7062805b66a6 /mnt/data02 ext4 defaults 0 0
    /mnt/data02/swapfile   none    swap    sw,pri=100    0   0
    /home/swapfile  none  swap  sw  0,pri=150 0

EDIT 2 Em resposta a um comentário abaixo, observei meu sistema executar uma operação que eu sabia que usaria toda a RAM disponível, mas não toda a troca disponível, e depois verifiquei dmesg durante e após a falha. O sistema trocou e tornou-se intermitentemente não responsivo (bom comportamento). Então, enquanto o swap estava com menos de 10% da capacidade, o Chrome travou ( Sorry, the program "chrome" closed unexpectedly. Your computer does not have enough free memory to automatically analyze the problem and send a report to the developers ). Tentando voltar para a saída do dmesg que eu estava assistindo, recebi uma mensagem de erro que declarava This window is not responding. Do you want to force the application to exit, or wait for it to respond . Eu selecionei 'esperar'. A área de trabalho reapareceu e o monitor do sistema gnome entrou e saiu várias vezes em cinza enquanto o sistema trocava. Quando eu chequei de volta, eu estava na tela de login do Ubuntu. Eu entrei normalmente ... todos os meus processos anteriores foram eliminados e fui recebido com uma mensagem de erro idêntica à do Chrome em referência ao Xorg. A verificação do dmesg mostra apenas as duas mensagens a seguir:

[131267.206774] Watchdog[3433]: segfault at 0 ip 00007fe38faf9756 sp 00007fe37f393770 error 6 in chrome[7fe38be0a000+510c000]
[133329.875212] nvidia 0000:03:00.0: irq 106 for MSI/MSI-X

EDIT 3 Outros possíveis tópicos relevantes:

• O assassino da OOM pode ser chamado mesmo quando ainda há bastante memória disponível , embora eu ainda não tenha certeza de como verifique se a OOM foi chamada.
• Talvez alguns configuração de pages_low / min_free_kbytes me levaria para onde eu precisava, mais diretamente relacionado do que swappiness, mas não estou vendo o que [alguns sites sugerem que eu deveria encontrar em / proc / zoneinfo (Eu não posso postar um link: mariosmarduch.ulitzer.com/node/431838/mobile), mas isso pode ser porque eles não são específicos do Ubuntu?
• Não posso postar um link: www.linuxdevcenter.com/pub/a/linux/2006/11/30/linux-out-of-memory.html?page=1

Editar 4 Mensagens de erro adicionais:

[92315.165728] Watchdog[1319]: segfault at 0 ip 00007f7d0a417756 sp 00007f7cf9cb1770 error 6 in chrome[7f7d06728000+510c000]
[92656.478271] INFO: task Chrome_IOThread:1292 blocked for more than 120 seconds.
[92656.478275]       Tainted: P           OX 3.13.0-45-generic #74-Ubuntu
[92656.478276] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[92656.478278] Chrome_IOThread D ffff88207fc534c0     0  1292  32756 0x00000000
[92656.478282]  ffff881fa9d15dd8 0000000000000086 ffff881fad2ab000 ffff881fa9d15fd8
[92656.478285]  00000000000134c0 00000000000134c0 ffff881fad2ab000 ffff881fad2ab000
[92656.478288]  ffff881f5fce6260 ffff881f5fce6268 ffffffff00000000 ffff881f5fce6270
[92656.478290] Call Trace:
[92656.478299]  [<ffffffff817252d9>] schedule+0x29/0x70
[92656.478302]  [<ffffffff81727f55>] rwsem_down_write_failed+0x115/0x230
[92656.478307]  [<ffffffff81371d63>] call_rwsem_down_write_failed+0x13/0x20
[92656.478311]  [<ffffffff81314c90>] ? apparmor_file_mprotect+0x30/0x30
[92656.478313]  [<ffffffff8172796d>] ? down_write+0x2d/0x30
[92656.478318]  [<ffffffff8116ba7c>] vm_mmap_pgoff+0x6c/0xc0
[92656.478322]  [<ffffffff8117f916>] SyS_mmap_pgoff+0x116/0x270
[92656.478325]  [<ffffffff81018802>] SyS_mmap+0x22/0x30
[92656.478328]  [<ffffffff8173196d>] system_call_fastpath+0x1a/0x1f

    

Answer 1

Dependendo do que eles estão fazendo, os computadores com grandes quantidades de memória, como a sua, podem ter dificuldades quando a quantidade de memória livre (residente em vez de troca) ficar muito baixa. Às vezes (não é certo para a sua situação) as coisas podem ser melhoradas aumentando a quantidade mínima de memória mantida livre, ou / proc / sys / vm / min_free_kbytes. Pense nisso como manter mais espaço livre, de modo que as coisas fiquem mais fáceis de se movimentar e se reagrupar e descompactar. Tente um número muito grande primeiro, digamos 20G, e se isso ajudar a tentar reduzi-lo. Você também pode se ajudar assistindo "free" cuidadosamente, na tentativa de correlacionar os problemas com alguma memória mínima disponível.

Método 1 (script executado como sudo):

#! /bin/bash
cat /proc/sys/vm/min_free_kbytes

echo "20000000" > /proc/sys/vm/min_free_kbytes

cat /proc/sys/vm/min_free_kbytes

Método 2 (comando direto):

echo "20000000" | sudo tee /proc/sys/vm/min_free_kbytes

    

Answer 2

Para descobrir se seus processos foram mortos pelo killer da OOM, você pode inspecionar o resultado deste comando:

sudo egrep -ri 'killed process' /var/log/ | grep -v auth.log

Se este for o caso, você pode querer olhar para o artigo sobre como matar o OOM Killer. link