Apache sem resposta (site inativo) ou travamentos, configuração de MaxRequestWorkers atingida

2

Essa pergunta é sobre o Apache travar repetidamente e, embora seja executado, não responde, ou seja, não consigo acessar o site, por isso estou tentando descobrir o motivo.

Meu site Owncloud servido pelo Apache 2.4.7 no Ubuntu 14.04 não está acessível. Para verificar o que está errado, executei o apachectl -S:

~$ sudo apachectl -S
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName' directive globally to suppress this message
VirtualHost configuration:
*:443                  oc.benopp.org (/etc/apache2/sites-enabled/000-default.conf:1)
*:80                   127.0.1.1 (/etc/apache2/sites-enabled/000-default.conf:18)
ServerRoot: "/etc/apache2"
Main DocumentRoot: "/var/www"
Main ErrorLog: "/var/log/apache2/error.log"
Mutex mpm-accept: using_defaults
Mutex watchdog-callback: using_defaults
Mutex rewrite-map: using_defaults
Mutex ssl-stapling: using_defaults
Mutex ssl-cache: using_defaults
Mutex default: dir="/var/lock/apache2" mechanism=fcntl 
PidFile: "/var/run/apache2/apache2.pid"
Define: DUMP_VHOSTS
Define: DUMP_RUN_CFG
User: name="www-data" id=33
Group: name="www-data" id=33

Isso não parece explicar o problema. O error.log diz isto:

[Wed Jan 07 19:07:13.384687 2015] [ssl:warn] [pid 1699] AH01906: RSA server certificate is a CA certificate (BasicConstraints: CA == TRUE !?)
[Wed Jan 07 19:07:13.389319 2015] [mpm_prefork:notice] [pid 1699] AH00163: Apache/2.4.7 (Ubuntu) mod_gnutls/0.5.10 PHP/5.5.9-1ubuntu4.5 OpenSSL/1.0.1f configured -- resuming normal operations
[Wed Jan 07 19:07:13.389359 2015] [core:notice] [pid 1699] AH00094: Command line: '/usr/sbin/apache2'
[Wed Jan 07 19:08:01.788631 2015] [mpm_prefork:error] [pid 1699] AH00161: server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting

Não entendo como o Max solicita as configurações pode ser alcançado somente comigo usando o site. Estou certo em assumir que, embora eu seja o único a tentar acessar Owncloud para baixar alguns arquivos ou alterar configurações, isso nunca deve causar essa quantidade de solicitações?

Para dar uma olhada mais de perto, ativei mod_status . Infelizmente eu não sei o que fazer com a leitura, porque eu só aprendi como configurar o Apache para executar o meu Owncloud, e sou novo nisso. Parece um pouco longo para postar a leitura da página de status do servidor aqui inline, então eu fiz uma pasta : link

Assim, todos os processos estão "enviando resposta", exceto que eu não sei a quê, porque não estou enviando nenhuma solicitação, e o servidor está realmente desconectado da internet agora. Na documentação, é explicado como procurar problemas que estão causando cargas de trabalho excessivas, mas estou tendo problemas para conseguir que o Top mostre algo que eu possa usar. Parece que a carga da CPU realmente não é, não há cargas altas para serem vistas. Você pode dizer qual é o problema desta leitura?

EDIT2: outro acidente aconteceu algumas horas atrás, aqui está uma parte que parece relevante do error.log:

início do arquivo:

ProblemType: Crash
Architecture: amd64
CrashCounter: 1
Date: Tue Jan  6 13:50:05 2015
DistroRelease: Ubuntu 14.04
ExecutablePath: /usr/sbin/apache2
ExecutableTimestamp: 1406039884
ProcCmdline: /usr/sbin/apache2 -k start
ProcCwd: /etc/apache2
ProcEnviron:
 PATH=(custom, no user)
 LANG=C
ProcMaps:
 7fd2a4000000-7fd2a8000000 rw-s 00000000 00:04 12964                      /dev/zero (deleted)
 7fd2a8000000-7fd2a8021000 rw-p 00000000 00:00 0 
 7fd2a8021000-7fd2ac000000 ---p 00000000 00:00 0 
 7fd2aced8000-7fd2acedd000 r-xp 00000000 08:01 266060                     /lib/x86_64-linux-gnu/libnss_dns-2.19.so
 7fd2acedd000-7fd2ad0dc000 ---p 00005000 08:01 266060                     /lib/x86_64-linux-gnu/libnss_dns-2.19.so
 7fd2ad0dc000-7fd2ad0dd000 r--p 00004000 08:01 266060                     /lib/x86_64-linux-gnu/libnss_dns-2.19.so

e assim por diante e assim por diante, até fim do arquivo:

ProcStatus:
 Name:  apache2
 State: R (running)
 Tgid:  2807
 Ngid:  0
 Pid:   2807
 PPid:  1838
 TracerPid: 0
 Uid:   33  33  33  33
 Gid:   33  33  33  33
 FDSize:    64
 Groups:    33 
 VmPeak:      525052 kB
 VmSize:      524944 kB
 VmLck:        0 kB
 VmPin:        0 kB
 VmHWM:    23680 kB
 VmRSS:    23680 kB
 VmData:       85112 kB
 VmStk:      136 kB
 VmExe:      592 kB
 VmLib:    74868 kB
 VmPTE:      712 kB
 VmSwap:           0 kB
 Threads:   1
 SigQ:  1/29106
 SigPnd:    0000000000000000
 ShdPnd:    0000000000000000
 SigBlk:    0000000000004000
 SigIgn:    0000000001001000
 SigCgt:    000000018c0042eb
 CapInh:    0000000000000000
 CapPrm:    0000000000000000
 CapEff:    0000000000000000
 CapBnd:    0000001fffffffff
 Seccomp:   0
 Cpus_allowed:  3
 Cpus_allowed_list: 0-1
 Mems_allowed:  00000000,00000001
 Mems_allowed_list: 0
 voluntary_ctxt_switches:   21
 nonvoluntary_ctxt_switches:    34
Signal: 11
Uname: Linux 3.13.0-43-generic x86_64
UserGroups: 
CoreDump: base64

então o CoreDump eu deletei.

    
por Ben Opp 07.01.2015 / 20:00

1 resposta

3

Isso soa como o seguinte bug postado na barra de lançamento: link

A versão curta é que parece que há um problema com o Cache de Usuários da APC para PHP 5, pelo menos a versão empacotada com o Ubuntu 14.04.

A correção parece ser para limpar o pacote php5-apcu e reiniciar o apache:

sudo apt-get purge php5-apcu
sudo service apache2 restart 

Acabei de fazer isso, então não tenho certeza se isso realmente vai consertar isso a longo prazo. Eu também estava vendo erros de APC no log de erros.

Se você encontrou uma solução diferente, adoraria ouvi-la.

    
por 25.02.2015 / 02:04

Tags