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

Я использую SmartMachine на Джойенте. Я полагаю, что это какая-то виртуальная машина под управлением Solaris. У нас есть веб-приложение на этом компьютере, работающее на Apache, PHP и MySQL. Это очень хорошо справляется с нашим умеренным объемом трафика. Однако каждую ночь с тех пор, как мы ушли жить. Сайт будет возвращать 403 Запрещенные ошибки, пока 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.02K для базового уровня, когда я пытался установить его на 65.5K. Я даже не уверен, что это правильное решение:

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
Источник

6 ответов

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

Источник

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

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

Источник

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

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

ps -ef | grep apache | wc -l

lsof -p <apache pid>

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

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

Источник

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

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

Источник

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

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

Правильно ли вы настроили 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" }'

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

Источник

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

/questions/560215/v-razreshenii-apache-otkazano/560232#560232

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

Источник
Другие вопросы по тегам