O Apache Crashes Toda Noite Devido a "Muitos Arquivos Abertos"

Question

O Apache Crashes Toda Noite Devido a "Muitos Arquivos Abertos"

#1 resposta do (1 votos)
#2 resposta do (1 votos)
#3 resposta do (1 votos)
#4 resposta do (0 votos)
#5 resposta do (0 votos)
#6 resposta do (0 votos)

1

Estou executando um SmartMachine no Joyent. Acredito que estes são algum tipo de máquina virtual executando o Solaris. Nós temos uma aplicação web nesta máquina rodando em Apache, PHP e MySQL. Ele lida muito bem com nossa quantidade moderada de tráfego. No entanto todas as noites desde que fomos ao vivo. O site começará a retornar 403 erros proibidos até que o Apache seja reiniciado. Olho rápido no log de erros do Apache revela o seguinte:

[Tue Oct 26 23:13:00 2010] [error] server reached MaxClients setting, consider raising the MaxClients setting
[Wed Oct 27 13:09:40 2010] [error] (24)Too many open files: Cannot open SSLSessionCache DBM file '/var/run/ssl_scache' for reading (fetch)
[Wed Oct 27 13:09:40 2010] [error] (24)Too many open files: Cannot open SSLSessionCache DBM file '/var/run/ssl_scache' for writing (store)
[Wed Oct 27 13:09:40 2010] [error] [client 98.25.133.36] PHP Fatal error:  Unknown: Failed opening required '/home/jill/web/content/index.php' (include_path='.:/opt/local/lib/php') in Unknown on line 0, referer: https://[redacted]/presentations/present#
[Wed Oct 27 13:09:42 2010] [error] (24)Too many open files: Cannot open SSLSessionCache DBM file '/var/run/ssl_scache' for reading (fetch)
[Wed Oct 27 13:09:42 2010] [error] (24)Too many open files: Cannot open SSLSessionCache DBM file '/var/run/ssl_scache' for writing (store)
[Wed Oct 27 13:09:42 2010] [crit] [client 68.193.4.75] (24)Too many open files: /home/jill/web/content/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable, referer: https://[redacted]/presentations/present#
[Wed Oct 27 13:09:43 2010] [error] (24)Too many open files: Cannot open SSLSessionCache DBM file '/var/run/ssl_scache' for reading (fetch)
[Wed Oct 27 13:09:43 2010] [error] (24)Too many open files: Cannot open SSLSessionCache DBM file '/var/run/ssl_scache' for writing (store)
[Wed Oct 27 13:09:43 2010] [crit] [client 72.28.224.201] (24)Too many open files: /home/jill/web/content/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable, referer: https://[redacted]/presentations/present#
[Wed Oct 27 13:09:44 2010] [error] (24)Too many open files: Cannot open SSLSessionCache DBM file '/var/run/ssl_scache' for reading (fetch)
[Wed Oct 27 13:09:44 2010] [error] (24)Too many open files: Cannot open SSLSessionCache DBM file '/var/run/ssl_scache' for writing (store)
[Wed Oct 27 13:09:44 2010] [crit] [client 72.28.224.201] (24)Too many open files: /home/jill/web/content/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable, referer: https://[redacted]/presentations/present#

As últimas três linhas são repetidas para cada solicitação feita ao servidor. Eu estou realmente em uma perda de como evitar que isso aconteça. Eu tentei aumentar o número de arquivos que podem ser abertos usando o prctl, mas não devo usá-lo corretamente porque o prctl retorna 1.02K para o básico quando tentei configurá-lo para 65.5K. Eu nem tenho certeza se essa é uma solução sólida:

prctl -i process -n process.max-file-descriptor 'pgrep httpd'
process: 18284: /opt/local/sbin/httpd -k start
NAME    PRIVILEGE       VALUE    FLAG   ACTION                       RECIPIENT
process.max-file-descriptor
        basic           1.02K       -   deny                             18284
        privileged      65.5K       -   deny                                 -
        system          2.15G     max   deny                                 -

process: 18285: /opt/local/sbin/httpd -k start
NAME    PRIVILEGE       VALUE    FLAG   ACTION                       RECIPIENT
process.max-file-descriptor
        basic           1.02K       -   deny                             18285
        privileged      65.5K       -   deny                                 -
        system          2.15G     max   deny                                 -

Então, qual é a melhor maneira de rastrear e corrigir um problema como este?

UPDATE

aqui está a saída de pfiles para o processo de httpd raiz.

[root@fe5txrad ~]# pfiles 18269
18269:  /opt/local/sbin/httpd -k start
  Current rlimit: 1024 file descriptors
   0: S_IFCHR mode:0666 dev:304,8 ino:3020727013 uid:0 gid:3 rdev:13,2
      O_RDONLY
      /dev/null
   1: S_IFCHR mode:0666 dev:304,8 ino:3020727013 uid:0 gid:3 rdev:13,2
      O_WRONLY|O_CREAT|O_TRUNC
      /dev/null
   2: S_IFREG mode:0640 dev:182,65550 ino:362926 uid:0 gid:0 size:20551848
      O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE
      /var/log/httpd/error.log
   3: S_IFDOOR mode:0444 dev:313,0 ino:38 uid:0 gid:0 size:0
      O_RDONLY|O_LARGEFILE FD_CLOEXEC  door to nscd[18176]
      /var/run/name_service_door
   4: S_IFSOCK mode:0666 dev:311,0 ino:43693 uid:0 gid:0 size:0
      O_RDWR|O_NONBLOCK FD_CLOEXEC
        SOCK_STREAM
        SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152)
        sockname: AF_INET 0.0.0.0  port: 80
   5: S_IFSOCK mode:0666 dev:311,0 ino:42512 uid:0 gid:0 size:0
      O_RDWR|O_NONBLOCK FD_CLOEXEC
        SOCK_STREAM
        SO_REUSEADDR,SO_KEEPALIVE,SO_SNDBUF(49152),SO_RCVBUF(49152)
        sockname: AF_INET 0.0.0.0  port: 443
   6: S_IFIFO mode:0000 dev:301,0 ino:8763127 uid:0 gid:0 size:0
      O_RDWR|O_NONBLOCK FD_CLOEXEC
   7: S_IFIFO mode:0000 dev:301,0 ino:8763127 uid:0 gid:0 size:0
      O_RDWR FD_CLOEXEC
   8: S_IFREG mode:0640 dev:182,65550 ino:362927 uid:0 gid:0 size:1450493
      O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE FD_CLOEXEC
      /var/log/httpd/access.log
   9: S_IFREG mode:0644 dev:182,65550 ino:369102 uid:1000 gid:1000 size:528239971
      O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE FD_CLOEXEC
      /home/jill/logs/access_log
  10: S_IFREG mode:0644 dev:182,65550 ino:369102 uid:1000 gid:1000 size:528239971
      O_WRONLY|O_APPEND|O_CREAT|O_LARGEFILE FD_CLOEXEC
      /home/jill/logs/access_log
  11: S_IFREG mode:0644 dev:308,39 ino:3386326219 uid:0 gid:0 size:0
      O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE FD_CLOEXEC
  12: S_IFREG mode:0644 dev:308,39 ino:3088492558 uid:0 gid:0 size:0
      O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE FD_CLOEXEC
      advisory write lock set by process 7350
  13: S_IFSOCK mode:0666 dev:311,0 ino:6452 uid:0 gid:0 size:0
      O_RDWR FD_CLOEXEC
        SOCK_STREAM
        SO_SNDBUF(16384),SO_RCVBUF(5120)
        sockname: AF_UNIX

php solaris apache-2.2 max-file-descriptors

por macinjosh 27.10.2010 / 15:45

6 respostas

Tags php solaris apache-2.2 max-file-descriptors

Meu servidor linux foi atacado? Permissões em scripts cron?

score 1 · Answer 1

Você não mencionou quantas conexões você tem como máximo quando começa a receber esses erros.

Você pode usar ferramentas / comandos como:

ps -ef | grep apache | wc -l

lsof -p <apache pid>

netstat -anp | grep 80 | grep -i ESTABLISHED | wc -l

O primeiro comando informa quantos processos do apache em seu sistema. O segundo comando informa quantos arquivos / conexões abertas o processo do apache possui. Claro, você precisa substituir com o valor real. O terceiro comando informa quantas conexões estabelecidas você tem.

score 1 · Answer 2

Uma vez eu me queimei por algo similar. Uma coisa adicional que você pode querer verificar - que o PHP não está sugando os arquivos também. Se o PHP estiver armazenando informações da sessão no disco, uma sobrecarga repentina de solicitações pode sugar todos os arquivos também.

score 1 · Answer 3

Se você tiver boa memória e CPU, pode aumentar o número não. de arquivos abertos limite via comando ulimit

ulimit -n 32667 (pode ser mais alto que isso também)

score 0 · Answer 4

Eu acho que o erro "Muitos arquivos abertos" pode ser um equívoco. Existem várias referências à incapacidade de ler / gravar em / var / run, que é a memória virtual em terra solaris.

Algumas perguntas:

Você configurou o apache corretamente para lidar com a carga da quantidade de recursos disponível? Quantos segmentos filhos você tem permissão para bifurcar? Quanta memória cada thread leva? Quanta troca você configurou?

Um útil liner para descobrir quantos processos de memória httpd estão usando no total:

for i in 'pgrep httpd'; do pmap -x $i | nawk '/total/ {a+=$4} END { print a /1024" MB" }'; done | nawk '{a+=$1} END { print a " MB" }'

Tenho certeza de que alguém poderia colocar isso de forma mais eloquente, mas funciona para mim. h.

score 0 · Answer 5

Se você tiver boa memória e CPU, pode aumentar o número não. de arquivos abertos limite via comando ulimit

ulimit -n 32667 (pode ser mais alto que isso também)

score 0 · Answer 6

Eu sei que essa é uma pergunta antiga, mas em outra pergunta houve uma resposta muito apropriada ao problema, pergunto-me se isso pode se aplicar a você também:

link

Basicamente, o Xdebug está vazando descritores de arquivos para ouvintes de conexão (desculpe se isso é tecnicamente incorreto, essa é a idéia) quando o cliente de depuração não está aberto. Para resolver o problema, verifique se o cliente do depurador está aberto quando o depurador remoto inicia uma sessão de depuração. Claro, uma solução melhor seria uma correção para o bug pelos desenvolvedores.