Назад | Перейти на главную страницу

Apache аварийно завершает работу каждую ночь из-за «слишком большого количества открытых файлов»

Я использую SmartMachine на Joyent. Я полагаю, что это какая-то виртуальная машина под управлением Solaris. У нас есть веб-приложение на этой машине, работающее на Apache, PHP и MySQL. Он очень хорошо справляется с нашим умеренным объемом трафика. Однако каждую ночь с тех пор, как мы вышли в эфир. Сайт начнет возвращать ошибку 403 Forbidden, пока не будет перезапущен Apache. Я быстро просматриваю журнал ошибок Apache, и он показывает следующее:

[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#

Последние три строки повторяются для каждого запроса к серверу. Я действительно не понимаю, как этого не допустить. Я попытался увеличить количество файлов, которые можно открыть с помощью prctl, но я не должен использовать его правильно, потому что prctl возвращает 1,02 КБ для базового уровня, когда я пытался установить его на 65,5 КБ. Я даже не уверен, что это правильное решение:

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                                 -

Итак, как лучше всего отследить и решить такую ​​проблему?

ОБНОВИТЬ

вот вывод pfiles для корневого процесса httpd.

[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

Если у вас хорошая память и процессор, вы можете увеличить число. ограничение количества открытых файлов командой ulimit

ulimit -n 32667 (тоже может быть выше)

Однажды я обжегся чем-то похожим. Еще одна вещь, которую вы можете захотеть проверить - это то, что PHP тоже не поглощает файлы. Если PHP хранит информацию о сеансе на диске, внезапная перегрузка запросов также может поглотить все файлы.

Вы не указали, сколько у вас соединений максимально, когда вы начинаете получать эти ошибки.

Вы можете использовать такие инструменты / команды, как:

ps -ef | grep apache | wc -l

lsof -p <apache pid>

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

Первая команда сообщает вам, сколько процессов apache в вашей системе. Вторая команда сообщает вам, сколько открытых файлов / соединений имеет процесс apache. Конечно, нужно заменить на реальную стоимость. Третья команда сообщает вам, сколько у вас установленных подключений.

Я думаю, что ошибка «Слишком много открытых файлов» может быть неправильным. Существуют различные ссылки на невозможность чтения / записи в / var / run, который является виртуальной памятью в Solaris.

Несколько вопросов:

Правильно ли вы настроили apache для обработки нагрузки при доступном количестве ресурсов? Сколько дочерних потоков вы можете разветвлять? Сколько памяти занимает каждый поток? Сколько свопа вы настроили?

Удобный лайнер для определения общего объема памяти, используемой процессами httpd:

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" }'

Я уверен, что кто-то мог бы выразить это более красноречиво, но у меня это работает. hth.

Если у вас хорошая память и процессор, вы можете увеличить число. ограничение количества открытых файлов командой ulimit

ulimit -n 32667 (тоже может быть выше)

Я знаю, что это старый вопрос, но по другому вопросу был очень удачный ответ на проблему, интересно, может ли он относиться и к вам:

https://superuser.com/a/829413/196842

По сути, Xdebug пропускает файловые дескрипторы для прослушивателей соединений (извините, если это технически неверно, это идея), когда клиент отладки не открыт. Чтобы решить эту проблему, убедитесь, что клиент отладчика открыт, когда удаленный отладчик запускает сеанс отладки. Конечно, лучшим решением было бы исправление ошибки разработчиками.