Linux usando swap inteiro, parando de responder enquanto há bastante RAM livre

Question

Estou com um problema estranho ultimamente:

Por vezes (não consigo reproduzir de propósito), o meu sistema está a utilizar toda a sua troca, apesar de existir RAM RAM mais que suficiente. Se isso acontecer, os sistemas então não responderão por alguns minutos, então o killer da OOM mata um processo "aleatório" que não ajuda muito, ou o servidor X. Se ele mata um processo "aleatório", o sistema não se torna responsivo (ainda não há troca, mas muita RAM livre); se ele mata X, a troca é liberada e o sistema se torna responsivo novamente.

Saída gratuita quando acontece:

$ free -htl
              total        used        free      shared  buff/cache   available
Mem:           7.6G        1.4G         60M        5.7G        6.1G        257M
Low:           7.6G        7.5G         60M
High:            0B          0B          0B
Swap:          3.9G        3.9G          0B
Total:          11G        5.4G         60M

uname -a:

Linux fedora 4.4.7-300.fc23.x86_64 #1 SMP Wed Apr 13 02:52:52 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

Swapiness:

cat /proc/sys/vm/swappiness 
5

Seção relevante no dmesg: link

tmpfs:

$ df -h -t tmpfs
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           3.8G  1.5M  3.8G   1% /dev/shm
tmpfs           3.8G  1.7M  3.8G   1% /run
tmpfs           3.8G     0  3.8G   0% /sys/fs/cgroup
tmpfs           3.8G  452K  3.8G   1% /tmp
tmpfs           776M   16K  776M   1% /run/user/42
tmpfs           776M   32K  776M   1% /run/user/1000

Meminfo: link

top -o SHR -n 1
Tasks: 231 total,   1 running, 230 sleeping,   0 stopped,   0 zombie
%Cpu(s):  8.5 us,  3.0 sy,  0.3 ni, 86.9 id,  1.3 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem :  7943020 total,   485368 free,   971096 used,  6486556 buff/cache
KiB Swap:  4095996 total,  1698992 free,  2397004 used.   989768 avail Mem 

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                             
 2066 mkamlei+  20   0 8342764 163908 145208 S   0.0  2.1   0:59.62 Xorg                                                
 2306 mkamlei+  20   0 1892816 138536  27168 S   0.0  1.7   1:25.47 gnome-shell                                         
 3118 mkamlei+  20   0  596392  21084  13152 S   0.0  0.3   0:04.86 gnome-terminal-                                     
 1646 gdm       20   0 1502632  60324  12976 S   0.0  0.8   0:01.91 gnome-shell                                         
 2269 mkamlei+  20   0 1322592  22440   8124 S   0.0  0.3   0:00.87 gnome-settings-                                     
  486 root      20   0   47048   8352   7656 S   0.0  0.1   0:00.80 systemd-journal                                     
 2277 mkamlei+   9 -11  570512  10080   6644 S   0.0  0.1   0:15.33 pulseaudio                                          
 2581 mkamlei+  20   0  525424  19272   5796 S   0.0  0.2   0:00.37 redshift-gtk                                        
 1036 root      20   0  619016   9204   5408 S   0.0  0.1   0:01.70 NetworkManager                                      
 1599 gdm       20   0 1035672  11820   5120 S   0.0  0.1   0:00.28 gnome-settings-                                     
 2386 mkamlei+  20   0  850856  24948   4944 S   0.0  0.3   0:05.84 goa-daemon                                          
 2597 mkamlei+  20   0 1138200  13104   4596 S   0.0  0.2   0:00.28 evolution-alarm                                     
 2369 mkamlei+  20   0 1133908  16472   4560 S   0.0  0.2   0:00.49 evolution-sourc                                     
 2529 mkamlei+  20   0  780088  54080   4380 S   0.0  0.7   0:01.14 gnome-software                                      
 2821 mkamlei+  20   0 1357820  44320   4308 S   0.0  0.6   0:00.23 evolution-calen                                     
 2588 mkamlei+  20   0 1671848  55744   4300 S   0.0  0.7   0:00.49 evolution-calen                                     
 2525 mkamlei+  20   0  613512   8928   4188 S   0.0  0.1   0:00.19 abrt-applet                                         

ipcs:

[mkamleithner@fedora ~]$ ipcs -m -t

------ Shared Memory Attach/Detach/Change Times --------
shmid      owner      attached             detached             changed             
294912     mkamleithn Apr 30 20:29:16      Not set              Apr 30 20:29:16     
393217     mkamleithn Apr 30 20:29:19      Apr 30 20:29:19      Apr 30 20:29:17     
491522     mkamleithn Apr 30 20:42:21      Apr 30 20:42:21      Apr 30 20:29:18     
524291     mkamleithn Apr 30 20:38:10      Apr 30 20:38:10      Apr 30 20:29:18     
786436     mkamleithn Apr 30 20:38:12      Not set              Apr 30 20:38:12     

[mkamleithner@fedora ~]$ ipcs

------ Message Queues --------
key        msqid      owner      perms      used-bytes   messages    

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status      
0x00000000 294912     mkamleithn 600        524288     2          dest         
0x00000000 393217     mkamleithn 600        2576       2          dest         
0x00000000 491522     mkamleithn 600        4194304    2          dest         
0x00000000 524291     mkamleithn 600        524288     2          dest         
0x00000000 786436     mkamleithn 600        4194304    2          dest         

------ Semaphore Arrays --------
key        semid      owner      perms      nsems     

[mkamleithner@fedora ~]$ ipcs -m -t

------ Shared Memory Attach/Detach/Change Times --------
shmid      owner      attached             detached             changed             
294912     mkamleithn Apr 30 20:29:16      Not set              Apr 30 20:29:16     
393217     mkamleithn Apr 30 20:29:19      Apr 30 20:29:19      Apr 30 20:29:17     
491522     mkamleithn Apr 30 20:42:21      Apr 30 20:42:21      Apr 30 20:29:18     
524291     mkamleithn Apr 30 20:38:10      Apr 30 20:38:10      Apr 30 20:29:18     
786436     mkamleithn Apr 30 20:38:12      Not set              Apr 30 20:38:12     

[mkamleithner@fedora ~]$ sudo grep 786436 /proc/*/maps
/proc/2084/maps:7ff4a56cc000-7ff4a5acc000 rw-s 00000000 00:05 786436                     /SYSV00000000 (deleted)
/proc/3984/maps:7f4574d00000-7f4575100000 rw-s 00000000 00:05 786436                     /SYSV00000000 (deleted)

[mkamleithner@fedora ~]$ sudo grep 524291 /proc/*/maps
/proc/2084/maps:7ff4a4593000-7ff4a4613000 rw-s 00000000 00:05 524291                     /SYSV00000000 (deleted)
/proc/2321/maps:7fa9b8a67000-7fa9b8ae7000 rw-s 00000000 00:05 524291                     /SYSV00000000 (deleted)

[mkamleithner@fedora ~]$ sudo grep 491522 /proc/*/maps
/proc/2084/maps:7ff4a4ad3000-7ff4a4ed3000 rw-s 00000000 00:05 491522                     /SYSV00000000 (deleted)
/proc/2816/maps:7f2763ba1000-7f2763fa1000 rw-s 00000000 00:05 491522                     /SYSV00000000 (deleted)

[mkamleithner@fedora ~]$ sudo grep 393217 /proc/*/maps
/proc/2084/maps:7ff4b1a60000-7ff4b1a61000 rw-s 00000000 00:05 393217                     /SYSV00000000 (deleted)
/proc/2631/maps:7fb89be79000-7fb89be7a000 rw-s 00000000 00:05 393217                     /SYSV00000000 (deleted)

[mkamleithner@fedora ~]$ sudo grep 294912 /proc/*/maps
/proc/2084/maps:7ff4a5510000-7ff4a5590000 rw-s 00000000 00:05 294912                     /SYSV00000000 (deleted)
/proc/2582/maps:7f7902dd3000-7f7902e53000 rw-s 00000000 00:05 294912                     /SYSV00000000 (deleted)

obtendo os nomes dos processos:

[mkamleithner@fedora ~]$ ps aux | grep 2084
mkamlei+  2084  5.1  2.0 8149580 159272 tty2   Sl+  20:29   1:10 /usr/libexec/Xorg vt2 -displayfd 3 -auth /run/user/1000/gdm/Xauthority -nolisten tcp -background none -noreset -keeptty -verbose 3
mkamlei+  5261  0.0  0.0 118476  2208 pts/0    S+   20:52   0:00 grep --color=auto 2084
[mkamleithner@fedora ~]$ ps aux | grep 3984
mkamlei+  3984 11.4  3.6 1355100 293240 tty2   Sl+  20:38   1:38 /usr/lib64/firefox/firefox
mkamlei+  5297  0.0  0.0 118472  2232 pts/0    S+   20:52   0:00 grep --color=auto 3984

Devo também postar os resultados para os outros shmids? Eu realmente não sei como interpretar a saída.

Como posso corrigir isso?

Edit: Iniciando o jogo "Papers, Please" sempre parece acionar esse problema depois de algum tempo. Também acontece às vezes quando este jogo não é iniciado.

Edit2: Parece ser um problema X. No caminho, isso não acontece. Pode ser devido a configurações personalizadas no xorg.conf.

Final Edit: Para qualquer um que tenha o mesmo problema: Eu estava usando o DRI 2. Mudar para o DRI 3 também corrige o problema. esta é a minha seção relevante no xorg.conf:

Section "Device"
    Identifier  "Intel Graphics"
    Driver      "intel"
    Option      "AccelMethod"     "sna" # 
    Option      "Backlight"       "intel_backlight"
    BusID       "PCI:0:2:0"
    Option      "DRI"             "3" #here
    Option      "TearFree"        "true"
EndSection

O arquivo relevante no meu sistema está em /usr/share/X11/xorg.conf.d/.

    

Answer 1

shared Memory used (mostly) by tmpfs (Shmem in /proc/meminfo, available on kernels 2.6.32, displayed as zero if not available)>

Portanto, a definição da página de manual de Shared não é tão útil quanto poderia ser :(. Se o uso de tmpfs não refletir esse alto valor de Shared, o valor deve representar algum processo ( es) "quem fez mmap () com MAP_SHARED | MAP_ANONYMOUS" (ou memória compartilhada System V).

6G de memória compartilhada em um sistema 8G ainda é um lote . Sério, você não quer isso, pelo menos não em um desktop.

É estranho que isso também contribua para "buff / cache". Mas eu fiz um teste rápido com python e é assim que funciona.

Para mostrar os processos com mais memória compartilhada, use top -o SHR -n 1 .

Memória compartilhada do System V

Finalmente, é possível que você tenha algum software legado horrível que use segmentos de memória compartilhada do sistema V. Se eles forem vazados , eles não serão exibidos em top : (.

Você pode listá-los com ipcs -m -t . Espero que o mais recentemente criado ainda esteja em uso. Pegue o número shmid e, por exemplo,

$ ipcs -m -t

------ Shared Memory Attach/Detach/Change Times --------
shmid      owner      attached             detached             changed             
3538944    alan       Apr 30 20:35:15      Apr 30 20:35:15      Apr 30 16:07:41     
3145729    alan       Apr 30 20:35:15      Apr 30 20:35:15      Apr 30 15:04:09     
4587522    alan       Apr 30 20:37:38      Not set              Apr 30 20:37:38     

# sudo grep 4587522 /proc/*/maps

- > então os números mostrados nos caminhos / proc são o pid dos processos que usam o SHM. (Então você poderia, por exemplo, grep a saída de ps para esse número pid).

contradições aparentes

1. O Xorg tem 8G mapeado. Mesmo que você não tenha RAM separada da placa de vídeo. Só tem 150M residente. Não é que o resto seja trocado, porque você não tem espaço de troca suficiente.

2. Os segmentos SHM mostrados por ipcs estão todos anexados a dois processos. Portanto, nenhum deles vazou, e todos eles devem aparecer na coluna SHR de top (double-count even). Tudo bem se o número de páginas usadas for menor que o tamanho do segmento de memória, isso significa apenas que há páginas que não foram usadas. Mas free diz que temos 6 GB de memória compartilhada alocada para contabilizar, e não conseguimos encontrar isso.

Answer 2

shared Memory used (mostly) by tmpfs (Shmem in /proc/meminfo, available on kernels 2.6.32, displayed as zero if not available)

tmpfs é swappable. Você tem o (s) sistema (s) de arquivos tmpfs que estão sendo preenchidos além dos limites seguros. Para comparação, o sistema em que estou digitando tem 200M compartilhados. O 6G é muito em um sistema 8G rodando um desktop, com coisas como dropbox e Steam ao mesmo tempo.

Você pode usar as ferramentas normais para descobrir quais arquivos estão causando o problema. Embora seja teoricamente possível que os arquivos desapareçam quando sua sessão X for interrompida.

$ df -h -t tmpfs
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           1.9G  1.7M  1.9G   1% /dev/shm
tmpfs           1.9G  1.6M  1.9G   1% /run
tmpfs           1.9G     0  1.9G   0% /sys/fs/cgroup
tmpfs           1.9G   80K  1.9G   1% /tmp
tmpfs           376M   20K  376M   1% /run/user/42
tmpfs           376M   20K  376M   1% /run/user/1000

Limite as montagens do seu tmpfs para sobreviver aos seus problemas, ganhe a oportunidade de analisá-las e talvez até mesmo acione uma mensagem de erro útil do software que as preenche.

Por padrão, cada tmpfs é limitado a metade da RAM disponível.

Portanto, é desejável não proliferar várias montagens tmpfs com limites padrão. As distribuições não são tão boas quanto deveriam, como você pode ver acima, para o meu sistema de 4GB.

Aparentemente é possível alterar os limites em tempo de execução com mount -oremount,size=10% /tmp .

Você pode colocar seus comandos de remount em algum lugar no momento da inicialização, por exemplo, /etc/rc.local (pode requerer systemctl enable rc-local ). Nota: /run/user/* provavelmente serão montados após a execução do seu script; espero que eles já tenham limites sensatos.

As montagens tmpfs padrão tendem a não ser listadas em /etc/fstab . Em systemd, você pode modificar a /tmp mount com, por exemplo, %código%. Caso contrário, você poderia percorrer os scripts do sistema para encontrar onde eles montam / tmp; pode usar um arquivo de configuração que você pode editar. Outra opção válida para systemctl edit tmp.mount seria desabilitar completamente a montagem tmpfs ( /tmp ), deixando apenas os programas gravarem no sistema de arquivos raiz.