Eliminando o OOM e o crash do mysqld consecutivo

Question

Estou tentando eliminar o problema de falta de memória que parece estar atingindo mysqld service. O serviço morre de forma totalmente aleatória - às vezes uma vez por semana, às vezes a cada dois dias.

Meu VPS tem 6 GB de RAM e nenhum arquivo de swap (meu provedor não permite / suporta swaps). Meu aplicativo é PHP -based ( Symfony framework) e é executado em Apache 2.2 .

Esta noite eu observei um pico de uso de RAM. Lamentavelmente, não consegui capturar uma saída exata de free -m , mas lembro que -/+ buffers/cache da coluna free estava em torno de 1G. O uso de RAM estava subindo e descendo de 4.8G para 5.2G.

Durante a janela de manutenção, encerrei httpd , mysqld e mongod , depois do qual obtive a seguinte free -m output:

[root@XXXYYYZZZ ~]# free -m
             total       used       free     shared    buffers     cached
Mem:          6144       4916       1227          0          0       1207
-/+ buffers/cache:       3709       2434
Swap:            0          0          0

Minha pergunta é o que está acontecendo com esses 3709M de memória usada? O comando top não revela muito:

top - 19:54:58 up 3 days,  6:35,  2 users,  load average: 0.00, 0.01, 0.05
Tasks:  21 total,   1 running,  20 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   6291456k total,  5034692k used,  1256764k free,        0k buffers
Swap:        0k total,        0k used,        0k free,  1236060k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
    1 root      20   0 19236 1180  932 S  0.0  0.0   0:00.02 init
    2 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kthreadd/23992
    3 root      20   0     0    0    0 S  0.0  0.0   0:00.00 khelper/23992
  140 root      16  -4 10644  520  248 S  0.0  0.0   0:00.00 udevd
  482 root      20   0  179m 1252  828 S  0.0  0.0   0:00.04 rsyslogd
  493 dbus      20   0 21408  616  376 S  0.0  0.0   0:00.00 dbus-daemon
  510 root      20   0 66632 1232  520 S  0.0  0.0   0:00.00 sshd
  517 root      20   0 22184  904  668 S  0.0  0.0   0:00.00 xinetd
  870 root      20   0 66828  924  276 S  0.0  0.0   0:00.00 saslauthd
  871 root      20   0 66828  680   32 S  0.0  0.0   0:00.00 saslauthd
  886 root      20   0 83080 2664  840 S  0.0  0.0   0:04.99 sendmail
  894 smmsp     20   0 78668 2108  648 S  0.0  0.0   0:00.03 sendmail
  944 root      20   0  114m 1232  628 S  0.0  0.0   0:00.81 crond
  955 root      20   0 88304  21m 1784 S  0.0  0.3   0:05.25 miniserv.pl
22840 root      20   0 96276 4448 3460 S  0.0  0.1   0:00.09 sshd
22842 root      20   0  105m 1988 1524 S  0.0  0.0   0:00.03 bash
22985 root      20   0 96300 4168 3164 S  0.0  0.1   0:00.03 sshd
22987 root      20   0 57848 2340 1624 S  0.0  0.0   0:00.04 sftp-server
23313 root      20   0 96276 4472 3460 S  0.0  0.1   0:00.68 sshd
23315 root      19  -1  105m 2024 1544 S  0.0  0.0   0:00.16 bash
25080 root      19  -1 14900 1220  992 R  0.0  0.0   0:00.00 top

Estou ciente de que o Linux faz o cache na RAM, mas eu diria que isso é bastante irregular. Eu posso estar errado e, de fato, espero estar.

Depois de ler atentamente a chamada drop_cache que eu poderia executar para, bem, largar o cache, decidi tentar ir com isso, apenas para obter isso:

[root@XXXYYYZZZ ~]# sync; echo 3 > /proc/sys/vm/drop_caches
-bash: /proc/sys/vm/drop_caches: Permission denied

Então, eu não consigo baixar os caches, não consigo criar um arquivo de swap e estou voando muito perto do sol com consumo de RAM (e ganhei algumas queimaduras devido a mysqld de falhas).

Alguém sabe como investigar isso melhor?

Se eu for derrubar meu provedor de VPS, com o qual estou ficando muito irritado recentemente, preciso de provas sólidas de que não estou interpretando mal os dados de desempenho ou, pior, que o processo legítimo está consumindo muita RAM .

Muito obrigado!

Atualizar

Eu corri o virt-what e recebi openvz

Update2: entradas de mensagens do OOM:

/var/log/messages-20161009:Oct  2 16:43:43 XXXYYYZZZ kernel: [56050139.271683] Out of memory in UB 23992: OOM killed process 22029 (mysqld) score 0 vm:5044284kB, rss:656944kB, swap:8280kB
/var/log/messages-20161009:Oct  2 16:43:55 XXXYYYZZZ kernel: [56050150.552528] Out of memory in UB 23992: OOM killed process 30486 (mysqld) score 0 vm:310088kB, rss:214456kB, swap:0kB
/var/log/messages-20161009:Oct  5 12:56:17 XXXYYYZZZ kernel: [56295842.893210] Out of memory in UB 23992: OOM killed process 13284 (mysqld) score 0 vm:5066092kB, rss:694760kB, swap:40kB
/var/log/messages-20161023:Oct 22 17:54:09 XXXYYYZZZ kernel: [1219419.032263] Out of memory in UB 23992: OOM killed process 789 (mysqld) score 0 vm:5057832kB, rss:698980kB, swap:0kB
/var/log/messages-20161023:Oct 22 17:54:20 XXXYYYZZZ kernel: [1219428.340161] Out of memory in UB 23992: OOM killed process 21700 (mysqld) score 0 vm:310088kB, rss:271892kB, swap:0kB
/var/log/messages-20161030:Oct 29 12:14:47 XXXYYYZZZ kernel: [1804212.497098] Out of memory in UB 23992: OOM killed process 25691 (mysqld) score 0 vm:5057548kB, rss:690164kB, swap:0kB
/var/log/messages-20161030:Oct 29 12:15:06 XXXYYYZZZ kernel: [1804222.381820] Out of memory in UB 23992: OOM killed process 23659 (mysqld) score 0 vm:310088kB, rss:248376kB, swap:0kB

    

Answer 1

Primeiro, a menos que você esteja fazendo algum teste você , nunca precisará descartar os caches. O kernel Linux usa memória 'livre' para caches. Se algo solicitar memória e não estiver disponível em outro lugar, a solicitação será satisfeita a partir da memória cache.

Para começar a resolver seu problema, você deve procurar em seus registros. Eles devem conter informações do sistema OOM sobre o motivo pelo qual ele chegou e o que fez.

Como outros sugeriram, parece que você pode estar usando um container VPS (openvz etc). Se este for o caso, é provável que a sua única solução real seja mudar para um VPS diferente que utilize uma tecnologia de virtualização diferente, por ex. KVM, etc.

    

Answer 2

Erro que você obteve

[root@XXXYYYZZZ ~]# sync; echo 3 > /proc/sys/vm/drop_caches
-bash: /proc/sys/vm/drop_caches: Permission denied

É o resultado do noclobber ativado (man bash e procura por > |). Experimente assim ...

sync; echo 3 >| /proc/sys/vm/drop_caches

E, a propósito, você pode tentar começar com isso

sync; echo 2 >| /proc/sys/vm/drop_caches

Você também pode ver a saída do comando slabtop para ver o que está comendo o seu RAM. Não que isso ajude muito, mas pelo menos você saberá se está vindo de algum cache de placas ou não. Instale também o pacote sysstat e ative o sar com resolução de 1 minuto, para que você possa analisar o desempenho do sistema historicamente em vez de monitorar on-line em tempo real.