“Terlalu banyak file terbuka” di Mac OSX setelah menjalankan apache di PHP dengan XDebug selama beberapa waktu


13

Saya menjalankan Mac OS X 10.9.4, termasuk server web apache2 bawaan dengan PHP 5.5.14 dari brew (paket: php55, php55-intl, php55-pdo-pgsql, php55-xdebug).

Saat menjalankan pengaturan ini berfungsi dengan baik. Namun, setelah beberapa waktu, saya akan menjalankan 403 kesalahan untuk setiap permintaan. Saya telah mencari log kesalahan apache, dan menemukan sesuatu seperti berikut:

[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. {main}() /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. {main}() /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

Sepertinya file itu tidak bisa dibaca lagi, dan entah bagaimana mengembalikan 403. Saya sudah mengetahui tentang batas-batas tertentu, tetapi launchctl mengembalikan, saya memiliki batas keras tak terbatas pada file terbuka:

 ~ $ 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

Saya juga sudah mencoba untuk mengatur maxfiles ke 4096 dengan perintah launchctl limit maxfiles 4096 16384, tetapi masalah masih kembali setelah beberapa waktu. Ada ide apa lagi yang bisa saya periksa?

UPDATE : Ketika menjalankan lsof -c httpdperintah seperti yang disarankan oleh Gordon Davisson, saya dapat melihat bahwa ada banyak entri seperti berikut:

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

Saya dapat mengatakan bahwa aplikasi yang saya gunakan menggunakan websockets, dan juga menggunakan fallback ketika websockets tidak tersedia atau rekanannya tidak berjalan di server. Yang membingungkan saya adalah (CLOSED)-bagian, mengapa masih terdaftar?

PEMBARUAN : Setelah beberapa waktu saya mencari port cslistener, yang sebenarnya adalah 9000, yang mana lagi-lagi port xdebug sedang mendengarkan debugging jarak jauh. Jadi saya kira saya telah mendapatkan beberapa konfigurasi yang salah di sana, atau itu adalah bug di xdebug (Saya menggunakan XDebug 2.2.5, diinstal oleh minuman)

Jawaban:


14

Apakah Anda menggunakan PHPStorm dengan XDEBUG di Mac?

Saya memiliki masalah yang sama. Saya menemukan bug terbuka yang diajukan dengan XDEBUG di sini:

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

Memperbarui

Bug ini sekarang telah diperbaiki:

Saya baru saja menggabungkan tambalan oleh Sean Dubois, yang seharusnya memperbaikinya \ o /! Patch akan berada di 2.3.4 dan 2.4.0.

Saya percaya ini adalah komit: https://github.com/xdebug/xdebug/commit/6efc6588efc277d648a78b69c11c721992c996f9

Pastikan Anda menggunakan versi yang diperbarui dengan tambalan ini.


Tidak benar-benar solusi, tetapi saya pikir itu menjawab pertanyaan
Daniel Rotter

Pada dasarnya, Xdebug membocorkan deskriptor file untuk pendengar koneksi (maaf jika ini secara teknis salah, itulah idenya) ketika klien debugging tidak terbuka. Untuk mengatasi masalah, pastikan klien debugger terbuka ketika debugger jarak jauh memulai sesi debugging. Tentu saja, solusi yang lebih baik adalah perbaikan bug oleh pengembang.
mcdado

Ini juga terjadi dengan beberapa debugger terbuka (misalnya PhpStorm). Semoga mereka akan memperbaikinya :)
Steve Tauber

Ini cukup besar, saya berharap perbaikan akan segera diterbitkan.
Hubert Perron

1
Solusi lain adalah untuk set xdebug.remote_enable=0di php.iniuntuk mengubah koneksi remote Xdebug bila tidak menggunakan mereka. Diperlukan restart Apache.
Gregory Cosmo Haun

7

Saya cukup yakin Anda memiliki sesuatu yang berjalan di apache (mungkin modul PHP, tetapi sulit untuk memastikan) itu adalah deskriptor file yang bocor. Yaitu, membuka file dan kemudian membiarkannya terbuka tanpa batas. Jika ini masalahnya, meningkatkan batas file terbuka hanya akan membuatnya lebih lama untuk mencapai batas. Yang perlu Anda lakukan adalah melacak apa yang membuka semua file dan membiarkannya terbuka.

Anda mungkin dapat mengetahui apa yang terjadi dengan perintah lsof("LiSt Open Files"):

sudo lsof -c httpd

Jalankan ketika apache belum berjalan lama untuk melihat apa yang normal, lalu lagi ketika mencapai batas. Lihat di output kedua untuk banyak file tambahan yang tidak ada di daftar pertama. Perhatikan bahwa ini akan sedikit rumit oleh fakta bahwa itu akan mencantumkan file yang dibuka oleh semua proses httpd, dan (tergantung pada pengaturan apache Anda dan server load) mungkin ada sejumlah besar dari mereka; yang penting adalah jumlah file yang dibuka oleh satu proses, bukan total di semua proses server. Anda juga dapat menggunakan sudo lsof -p someprocessIDuntuk mendaftar hanya satu proses server pada satu waktu.

Semoga melihat file ekstra apa yang terbuka akan memberi Anda ide yang baik tentang apa yang membukanya dan membiarkannya terbuka.


Mencobanya, saya telah memperbarui pertanyaan.
Daniel Rotter

Saya tidak begitu akrab dengan arti sebenarnya dari keadaan soket TCP, tetapi bagi saya sepertinya koneksi ke mitra tidak tertutup dengan benar. Apakah itu berjalan pada port cslistener (nomor 9000)? Bagaimana tepatnya aplikasi Anda menutup koneksi ke rekanannya? Apakah mungkin menutup sesi TCP, tetapi bukan deskriptor file?
Gordon Davisson

1
Saya menemukan bahwa 9000 adalah port xdebug sedang mendengarkan, jadi mungkinkah ada kesalahan dalam ekstensi ini?
Daniel Rotter

3

Menambahkan baris berikut ke xdebug.ini juga memecahkan masalah bagi saya

xdebug.remote_autostart = 0

1

Saya mendapatkan hal yang sama dengan OSX 10.9.4 dan keduanya Apache 2.2 dan PHP 5.3 dari Brew.

Meskipun ini tidak benar-benar memperbaiki masalah, Anda dapat mengatasinya dengan mengatur pengaturan Apache MaxRequestsPerChild ke sesuatu seperti 10 - yang seharusnya baik untuk pengembangan.

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

Itu akan menyelamatkan Anda setidaknya dari harus me-restart apache sesering mungkin untuk menyingkirkan file-file yang bocor

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.