Uso de memória excepcionalmente alto em um VPS do CentOS com 512 RAM garantida

3

Estou trabalhando em uma aplicação web de tamanho médio, escrita em PHP e executada em um VPS com 512mb de RAM. O webapp ainda não foi lançado oficialmente, então não há muito tráfego acontecendo, apenas eu e algumas outras pessoas trabalhando nele.

Existe outro webapp ligeiramente menor, também hospedado nesta máquina, entre 4-5 outros pequenos sites estáticos.

Estamos executando o Centos 5 de 32 bits & cPanel / WHM.

Este é o resultado da execução de ps aux e, como você pode ver, não está usando 100% da RAM. No entanto, na visão geral do hypanel, ele é sempre mostrado usando aroun 500MB ram, apenas para executar o apache, o mysql e as versões com menor pegada de memória do servidor de e-mail, do servidor ftp, etc.

-bash-3.2# ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0   2156   664 ?        Ss   12:08   0:00 init [3]
root      1123  0.0  0.0   2260   548 ?        S<s  12:08   0:00 /sbin/udevd -d
root      1462  0.0  0.0   1812   568 ?        Ss   12:08   0:00 syslogd -m 0
named     1496  0.0  0.0   3808   820 ?        Ss   12:08   0:00 nsd
named     1497  0.0  0.0  10672   756 ?        S    12:08   0:00 nsd
named     1499  0.0  0.0   3880   584 ?        S    12:08   0:00 nsd
root      1514  0.0  0.1   7240  1064 ?        Ss   12:08   0:00 /usr/sbin/sshd
root      1522  0.0  0.0   2832   832 ?        Ss   12:08   0:00 xinetd -stayalive -pidfile /var/run/xinetd.pid
root      1534  0.0  0.1   3712  1328 ?        S    12:08   0:00 /bin/sh /usr/bin/mysqld_safe --datadir=/var/lib/mysql -
mysql     1667  0.0  2.9 225680 30884 ?        Sl   12:08   0:00 /usr/sbin/mysqld --basedir=/ --datadir=/var/lib/mysql -
mailnull  1766  0.0  0.1   9352  1100 ?        Ss   12:08   0:00 /usr/sbin/exim -bd -q60m
root      1797  0.0  0.0   2156   708 ?        Ss   12:08   0:00 /usr/sbin/dovecot
root      1798  0.0  0.0   2632  1012 ?        S    12:08   0:00 dovecot-auth
root      1816  0.0  3.0  38580 32456 ?        Ss   12:08   0:01 /usr/local/bin/spamd -d --allowed-ips=127.0.0.1 --pidfi
root      1839  0.0  1.6  63200 17496 ?        Ss   12:08   0:00 /usr/local/apache/bin/httpd -k start -DSSL
root      1846  0.0  0.1   5416  1468 ?        Ss   12:08   0:00 pure-ftpd (SERVER)
root      1848  0.0  0.1   6212  1244 ?        S    12:08   0:00 /usr/sbin/pure-authd -s /var/run/ftpd.sock -r /usr/sbin
root      1856  0.0  0.1   4492  1112 ?        Ss   12:08   0:00 crond
root      1864  0.0  0.0   2356   428 ?        Ss   12:08   0:00 /usr/sbin/atd
dovecot   1927  0.0  0.1   5196  1952 ?        S    12:08   0:00 pop3-login
dovecot   1928  0.0  0.1   5196  1948 ?        S    12:08   0:00 pop3-login
dovecot   1929  0.0  0.1   5316  2012 ?        S    12:08   0:00 imap-login
dovecot   1930  0.0  0.2   5416  2228 ?        S    12:08   0:00 imap-login
root      1939  0.0  0.1   3936  1964 ?        S    12:08   0:00 cPhulkd - processor
root      1963  0.0  0.8  15876  8564 ?        S    12:08   0:00 cpsrvd (SSL) - waiting for connections
root      1966  0.0  0.7  15172  7748 ?        S    12:08   0:00 cpdavd - accepting connections on 2077 and 2078
root      1990  0.0  0.2   5008  3136 ?        S    12:08   0:00 queueprocd - wait to process a task
root      2017  0.0  2.9  38580 31020 ?        S    12:08   0:00 spamd child
root      2018  0.0  0.5   8904  5636 ?        S    12:08   0:00 /usr/bin/perl /usr/local/cpanel/bin/leechprotect
nobody    2021  0.0  3.2  66512 33724 ?        S    12:08   0:00 /usr/local/apache/bin/httpd -k start -DSSL
nobody    2022  0.0  3.1  67812 33024 ?        S    12:08   0:00 /usr/local/apache/bin/httpd -k start -DSSL
nobody    2024  0.0  1.9  64364 20680 ?        S    12:08   0:00 /usr/local/apache/bin/httpd -k start -DSSL
root      2027  0.0  0.4   9000  4540 ?        S    12:08   0:00 tailwatchd
root      2032  0.0  0.1   4176  1836 ?        SN   12:08   0:00 cpanellogd - sleeping for logs
nobody    3096  0.0  1.9  64572 20264 ?        S    12:09   0:00 /usr/local/apache/bin/httpd -k start -DSSL
nobody    3097  0.0  2.8  66008 30136 ?        S    12:09   0:00 /usr/local/apache/bin/httpd -k start -DSSL
nobody    3098  0.0  2.8  65704 29752 ?        S    12:09   0:00 /usr/local/apache/bin/httpd -k start -DSSL
nobody    3099  0.0  3.1  67260 32816 ?        S    12:09   0:00 /usr/local/apache/bin/httpd -k start -DSSL
andrei    3448  0.0  0.1   3204  1632 ?        S    12:50   0:00 imap
nobody    3537  0.0  1.9  64308 20108 ?        S    13:01   0:00 /usr/local/apache/bin/httpd -k start -DSSL
nobody    3614  0.0  1.9  64576 20628 ?        S    13:10   0:00 /usr/local/apache/bin/httpd -k start -DSSL
nobody    3615  0.0  1.3  63200 14672 ?        S    13:10   0:00 /usr/local/apache/bin/httpd -k start -DSSL
root      3626  0.0  0.2  10232  2964 ?        Rs   13:14   0:00 sshd: root@pts/0
root      3648  0.0  0.1   3844  1600 pts/0    Ss   13:14   0:00 -bash
root      3826  0.0  0.0   2532   908 pts/0    R+   13:21   0:00 ps aux

Ultimamente, sem nenhuma alteração significativa na configuração, o uso da memória começou a aumentar e ultrapassar 512, fazendo com que o servidor virtual matasse o apache, basicamente matando nosso site no processo.

Aqui está o resultado de free -m :

-bash-3.2# free -m
             total       used       free     shared    buffers     cached
Mem:          1024        381        642          0          0          0
-/+ buffers/cache:        381        642
Swap:            0          0          0

Outro aviso:

O Apache parece ser morto quando o uso atinge 400 / 512mb de RAM. Isso não costumava acontecer antes. É muito estranho.

Você tem alguma ideia se isso é normal e mais recursos devem ser adquiridos? Acho que não, já que ainda não há muitos dados ou tráfego on-line.

Editar 2:

[Sat Apr 07 18:04:21 2012] [notice] Graceful restart requested, doing restart
[Sat Apr 07 18:04:22 2012] [notice] seg fault or similar nasty error detected in the parent process
(after manual restart)
[Sat Apr 07 18:28:51 2012] [notice] suEXEC mechanism enabled (wrapper: /usr/local/apache/bin/suexec)
etc.

Aqui está o log de uma das falhas do Apache. Isso é desconcertante.

    
por Andrei Bârsan 07.04.2012 / 12:33

2 respostas

0

free -m mostra que deve haver RAM livre suficiente. Quando um processo é morto devido à pouca RAM disponível, isso é chamado de "oom kill" m, em que "oom" significa o ut o f m emory.

Você pode até dizer ao Linux quais processos matar em que ordem quando esta situação ocorrer.

Além disso, o MySQL reserva muita memória RAM em nosso sistema, o que é normal. Você pode diminuir o valor editando o arquivo my.cnf e ajustando as diversas variáveis do arquivo de configuração do MySQL.

Além disso, você deve se esforçar para otimizar o Apache para manter o consumo de RAM baixo. Depende strongmente da sua aplicação PHP se o Apache e o PHP consomem muita memória RAM ou não.

Além disso, você deve criar um arquivo SWAP que o ajude no caso de sua memória ficar cheia.

    
por 07.04.2012 / 14:14
0

O log do apache mostra uma reinicialização normal, que pode ser devido à rotação do log: é a mesma hora todos os dias?

Essa reinicialização é executada em um problema de segfault ou similar, que pode ser devido a uma incompatibilidade de biblioteca. O PHP foi instalado independentemente do apache? Esse problema só começou após a atualização do cpanel (que pode ter atualizado alguma biblioteca ou outra)?

Tente parar e iniciar o apache: esse erro sempre ocorre? E se você desabilitar o php ou outros módulos?

Você deve considerar fazer disso uma nova pergunta, se ela não estiver relacionada ao uso da memória sobre o qual você perguntou pela primeira vez.

    
por 08.04.2012 / 15:50