Vazamento de memória no servidor da Web

Question

Portanto, ultimamente tenho tido alguns problemas de desempenho do servidor. Atualmente, estamos executando um servidor Fedora com 4 GB e 160 GB de espaço em disco. Estamos praticamente limpando o disco, com todos os arquivos que temos a bordo. Estamos executando vários sites com vários backups para cada site. Apenas um site realmente recebe tráfego. É um site de comércio eletrônico com boa quantidade de visitantes.

Ultimamente tem havido tempos de carregamento lentos e noto que nossa memória livre está ficando muito baixa (abaixo de um GB). Vou reiniciar o servidor (o que tenho que fazer 3 vezes por dia agora) e tudo ficará bem. Começamos com 2.2GB de memória liberada, mas depois de 3 ou 4 horas você percebe que a memória está ficando saturada e os tempos de carregamento são rastreados. Eu não consigo descobrir de onde isso está vindo ou se é hora de fazer o upgrade para um servidor melhor. Eu só não quero atualizar, em seguida, perceber que eu sou garrafa em algum lugar com pedidos MySQL.

Qualquer ideia ou sugestão será apreciada.

EDITAR

Existem 3 vhosts e eu tenho mais de 60.000 arquivos.

             total       used       free     shared    buffers     cached
Mem:          4003       3372        630          0        398       1717
-/+ buffers/cache:       1256       2746
Swap:         8189          0       8189

21:21:49 up 46 min,  1 user,  load average: 3.75, 4.20, 4.03

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  2      0 592728 409640 1838360    0    0   165   411  953  473  9  8 47 36  0

E aqui está o primeiro instantâneo.

 1356 mysql     20   0 1374m 219m 5320 S  5.6  5.5  14:06.21 mysqld
15796 root      20   0  103m  20m  440 D  1.0  0.5   0:04.42 sendmail
 1081 root      20   0  103m  20m  440 D  0.7  0.5   0:21.73 sendmail
24013 root      20   0 97416  22m 2648 D  0.7  0.6   0:15.15 mailq
 1525 root      20   0  247m 7980 3472 S  0.3  0.2   0:06.88 vlogger (access
 1530 apache    20   0  539m  13m 3008 S  0.3  0.3   0:03.56 httpd
 2399 apache    20   0  539m  12m 2748 S  0.3  0.3   0:00.85 httpd
 5763 root      20   0  121m 4932 3868 S  0.3  0.1   0:00.07 sshd
12326 apache    20   0  539m  12m 2992 S  0.3  0.3   0:00.38 httpd
12421 apache    20   0  539m  12m 2988 S  0.3  0.3   0:00.45 httpd
16396 apache    20   0  538m  12m 2284 S  0.3  0.3   0:00.09 httpd
17050 root      20   0 15368 1256  868 R  0.3  0.0   0:00.09 top
    1 root      20   0 37336 4104 1908 S  0.0  0.1   0:02.82 systemd
    2 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kthreadd
    3 root      20   0     0    0    0 S  0.0  0.0   0:00.03 ksoftirqd/0
    5 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 kworker/0:0H
    6 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kworker/u:0
    7 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 kworker/u:0H
    8 root      RT   0     0    0    0 S  0.0  0.0   0:00.11 migration/0
    9 root      RT   0     0    0    0 S  0.0  0.0   0:00.01 watchdog/0
   10 root      RT   0     0    0    0 S  0.0  0.0   0:00.14 migration/1
   12 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 kworker/1:0H
   13 root      20   0     0    0    0 S  0.0  0.0   0:00.02 ksoftirqd/1
   14 root      RT   0     0    0    0 S  0.0  0.0   0:00.01 watchdog/1
   15 root      RT   0     0    0    0 S  0.0  0.0   0:00.15 migration/2
   17 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 kworker/2:0H
   18 root      20   0     0    0    0 S  0.0  0.0   0:00.03 ksoftirqd/2
   19 root      RT   0     0    0    0 S  0.0  0.0   0:00.01 watchdog/2
   20 root      RT   0     0    0    0 S  0.0  0.0   0:00.11 migration/3
   22 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 kworker/3:0H
   23 root      20   0     0    0    0 S  0.0  0.0   0:00.02 ksoftirqd/3
   24 root      RT   0     0    0    0 S  0.0  0.0   0:00.01 watchdog/3
   25 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 cpuset
   26 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 khelper
   27 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kdevtmpfs
   28 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 netns
   29 root      20   0     0    0    0 S  0.0  0.0   0:00.00 xenwatch

    

Answer 1

Aumente o sar e imprima a tabela ps a cada minuto. Veja minha resposta detalhada aqui .

Na próxima vez que o servidor explodir, use sar -r para ajudar a rastrear quando aconteceu. Agora use a saída do ps-cronjob ou do meu wrapper perl para ps no github , para descobrir qual processo pode ter sido o culpado .

Digamos que o servidor explodiu entre as 12:00:00 e as 13:00:00. Use sar -r -s 12:00:00 -e 13:00:00 . A partir disso você deve ver um pico nos dados. (Se é mais fácil, existe um utilitário baseado em java para fazer gráficos, mas geralmente não vale a pena o aborrecimento.) Digamos que você veja um pico (ou um vale) às 12:15. Agora, digitalize a saída de ps em coluna durante um intervalo de tempo entre, por exemplo, 12:00 e 12:15, classifique-a por pid e, em seguida, por time e observe as colunas de memória:

awk '/^=== .* 12:00:/,/^=== .* 12:16:/' /var/log/sa/ps/today |
 sort -k 1n -k 16 

(As opções de classificação assumem que o tempo está na coluna 16, que pode ou não ser o caso). Agora você pode filtrar essa saída pelo awk novamente para encontrar diferenças entre as linhas de saída:

... | awk 'lastpid && lastpid==$1 && last != $0 { print} /^[0-9]/ { lastpid=$1;last=$0; }'

Esse é um filtro bem grosseiro. Para alguns processos (cuja linha de comando muda o tempo todo, como com mysql e postgresql e snmpd), isso não será muito útil, mas esperamos que você possa ajustar o awk para ajudá-lo a encontrar o (s) culpado (s).