«Слишком много файлов открыто» на Mac OSX после запуска apache в PHP с XDebug в течение некоторого времени

7434
Daniel Rotter

Я использую Mac OS X 10.9.4, включая встроенный веб-сервер apache2 с PHP 5.5.14 от brew (пакеты: php55, php55-intl, php55-pdo-pgsql, php55-xdebug).

При запуске этой настройки она работает довольно хорошо. Однако через некоторое время я буду запускать 403 ошибки для каждого запроса. Я посмотрел журнал ошибок Apache и нашел что-то вроде следующего:

[Fri Jul 25 05:28:18 2014] [error] [client 127.0.0.1] PHP Warning: require_once(/Users/daniel/Development/massiveart/sulu-complete/app/bootstrap.php.cache): failed to open stream: Too many open files in /Users/daniel/Development/massiveart/sulu-complete/web/website.php on line 10, referer: http://sulu.lo/de [Fri Jul 25 05:28:18 2014] [error] [client 127.0.0.1] PHP Stack trace:, referer: http://sulu.lo/de [Fri Jul 25 05:28:18 2014] [error] [client 127.0.0.1] PHP 1. () /Users/daniel/Development/massiveart/sulu-complete/web/website.php:0, referer: http://sulu.lo/de [Fri Jul 25 05:28:18 2014] [error] [client 127.0.0.1] PHP Fatal error: require_once(): Failed opening required '/Users/daniel/Development/massiveart/sulu-complete/web/../app/bootstrap.php.cache' (include_path='.:/usr/local/Cellar/php55/5.5.14/lib/php') in /Users/daniel/Development/massiveart/sulu-complete/web/website.php on line 10, referer: http://sulu.lo/de [Fri Jul 25 05:28:18 2014] [error] [client 127.0.0.1] PHP Stack trace:, referer: http://sulu.lo/de [Fri Jul 25 05:28:18 2014] [error] [client 127.0.0.1] PHP 1. () /Users/daniel/Development/massiveart/sulu-complete/web/website.php:0, referer: http://sulu.lo/de [Fri Jul 25 05:28:40 2014] [crit] [client 127.0.0.1] (24)Too many open files: /Users/daniel/Development/massiveart/sulu-complete/web/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable, referer: http://sulu.lo/de [Fri Jul 25 05:28:41 2014] [crit] [client 127.0.0.1] (24)Too many open files: /Users/daniel/Development/massiveart/sulu-complete/web/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable, referer: http://sulu.lo/de [Fri Jul 25 05:28:41 2014] [crit] [client 127.0.0.1] (24)Too many open files: /Users/daniel/Development/massiveart/sulu-complete/web/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable, referer: http://sulu.lo/de [Fri Jul 25 05:28:41 2014] [crit] [client 127.0.0.1] (24)Too many open files: /Users/daniel/Development/massiveart/sulu-complete/web/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable, referer: http://sulu.lo/de [Fri Jul 25 05:28:45 2014] [crit] [client 127.0.0.1] (24)Too many open files: /Users/daniel/Development/massiveart/sulu-complete/web/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable, referer: http://sulu.lo/de [Fri Jul 25 05:28:45 2014] [crit] [client 127.0.0.1] (24)Too many open files: /Users/daniel/Development/massiveart/sulu-complete/web/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable, referer: http://sulu.lo/de

Мне кажется, что файл больше не может быть прочитан, и он как-то возвращает 403. Я уже узнал об определенных пределах, но launchctl возвращает, у меня есть неограниченное жесткое ограничение на открытые файлы:

 ~ $ launchctl limit cpu unlimited unlimited filesize unlimited unlimited data unlimited unlimited stack 8388608 67104768 core 0 unlimited rss unlimited unlimited memlock unlimited unlimited maxproc 709 1064 maxfiles 256 unlimited

Я также уже пытался установить maxfiles на 4096 с помощью команды launchctl limit maxfiles 4096 16384, но проблема все еще возвращается через некоторое время. Есть идеи, что еще я могу проверить?

ОБНОВЛЕНИЕ : при выполнении lsof -c httpdкоманды, как предложено Гордоном Дэвиссоном, я вижу, что есть множество записей, подобных следующему:

httpd 1361 _www 15u IPv4 0xb306b48659f63853 0t0 TCP localhost:50603->localhost:cslistener (CLOSED)

Я могу сказать, что приложение, которое я использую, использует веб-сокеты, а также использует запасной вариант, когда веб-сокеты недоступны или аналог не запущен на сервере. Что меня смущает, так это (CLOSED)-part, почему он все еще указан?

ОБНОВЛЕНИЕ : Через некоторое время я посмотрел порт cslistener, который на самом деле является 9000, который снова является тем, какой порт xdebug прослушивает для удаленной отладки. Так что я думаю, что у меня там какая-то неправильная конфигурация, или это ошибка в xdebug (я использую XDebug 2.2.5, установленный brew)

12

4 ответа на вопрос

14
Steve Tauber

Вы используете PHPStorm с XDEBUG на Mac?

У меня та же проблема. Я нашел открытую ошибку, поданную с XDEBUG здесь:

http://bugs.xdebug.org/view.php?id=1070

Обновить

Эта ошибка теперь исправлена:

Я только что слил патч Шона Дюбуа, который должен исправить это \ o /! Патч будет в 2.3.4 и 2.4.0.

Я считаю, что это обязательство: https://github.com/xdebug/xdebug/commit/6efc6588efc277d648a78b69c11c721992c996f9

Убедитесь, что вы используете обновленную версию с этим патчем.

Не совсем решение, но я думаю, что оно отвечает на вопрос Daniel Rotter 9 лет назад 0
По сути, Xdebug пропускает файловые дескрипторы для прослушивателей соединений (извините, если это технически неверно, такова идея), когда клиент отладки не открыт. Чтобы решить эту проблему, убедитесь, что клиент отладчика открыт, когда удаленный отладчик начинает сеанс отладки. Конечно, лучшим решением было бы исправление ошибки разработчиками. mcdado 9 лет назад 0
Это также происходит с некоторыми открытыми отладчиками (например, PhpStorm). Надеюсь, они это исправят :) Steve Tauber 9 лет назад 0
Это довольно важно, я надеюсь, что исправление будет выпущено в ближайшее время. Hubert Perron 9 лет назад 0
Другой обходной путь - установить `xdebug.remote_enable = 0` в` php.ini`, чтобы отключить удаленные соединения xdebug, когда они не используются. Требуется перезагрузка Apache. Gregory Cosmo Haun 8 лет назад 1
Я использую 2.4.0 и все еще сталкиваюсь с этой проблемой в PHP 5.6 Jeff 7 лет назад 0
7
Gordon Davisson

I'm pretty sure you have something running in apache (probably the PHP module, but it's hard to be sure) that's leaking file descriptors. That is, it's opening files and then just leaving them open indefinitely. If this is the case, increasing the open file limit just makes it take longer to hit the limit. What you really need to do is track down what's opening all the files and leaving them open.

You can probably get some idea what's going on with the lsof("LiSt Open Files") command:

sudo lsof -c httpd

Run it when apache hasn't been running for long to see what's normal, then again when it hits the limit. Look in the second output for lots of additional files that aren't there in the first listing. Note that this will be complicated somewhat by the fact that it'll list the files opened by all httpd processes, and (depending on your apache settings and server load) there may be a large number of them; the important thing is the number of files opened by a single process, not the total across all server processes. You can also use sudo lsof -p someprocessID to list just a single server process at a time.

Hopefully seeing what the extra open files are will give you a good idea what's opening them and leaving them open.

Попробовал, обновил вопрос. Daniel Rotter 9 лет назад 0
Я не очень хорошо знаю точное значение состояний сокета TCP, но мне кажется, что соединения с контрагентом не закрываются должным образом. Это работает на порту cslistener (номер 9000)? Как именно ваше приложение закрывает соединения со своим коллегой? Возможно ли, что он закрывает сеанс TCP, но не дескриптор файла? Gordon Davisson 9 лет назад 0
Я узнал, что 9000 - это порт, который прослушивает xdebug, так возможно ли, что ошибка в этом расширении? Daniel Rotter 9 лет назад 1
3
Femi Veys

Добавление следующей строки в xdebug.ini также решило проблему для меня

xdebug.remote_autostart = 0
1
barryp

I'm getting the same thing with OSX 10.9.4 and both Apache 2.2 and PHP 5.3 from Brew.

While this doesn't actually fix the problem, you can contain it by setting the Apache MaxRequestsPerChild setting to something like 10 - which should be fine for development.

diff -r 2c0473b696fd -r acf809f04b17 apache2/2.2/httpd.conf --- a/apache2/2.2/httpd.conf Thu Aug 14 16:14:25 2014 -0500 +++ b/apache2/2.2/httpd.conf Thu Aug 14 16:19:10 2014 -0500 @@ -437,7 +437,7 @@ # necessary. # Server-pool management (MPM specific) -#Include /usr/local/etc/apache2/2.2/extra/httpd-mpm.conf +Include /usr/local/etc/apache2/2.2/extra/httpd-mpm.conf # Multi-language error messages #Include /usr/local/etc/apache2/2.2/extra/httpd-multilang-errordoc.conf diff -r 2c0473b696fd -r acf809f04b17 apache2/2.2/extra/httpd-mpm.conf --- a/apache2/2.2/extra/httpd-mpm.conf Thu Aug 14 16:14:25 2014 -0500 +++ b/apache2/2.2/extra/httpd-mpm.conf Thu Aug 14 16:19:10 2014 -0500 @@ -38,7 +38,7 @@ MinSpareServers 5 MaxSpareServers 10 MaxClients 150 - MaxRequestsPerChild 0 + MaxRequestsPerChild 10 </IfModule> # worker MPM

That should save you at least from having to restart apache every so often to get rid of those leaked files

Похожие вопросы