JoyentでSmartMachineを実行しています。これらは、Solarisを実行しているある種の仮想マシンであると私は信じています。このマシンには、Apache、PHP、およびMySQLで実行されているWebアプリケーションがあります。適度な量のトラフィックを非常にうまく処理します。しかし、私たちがライブになってから毎晩。 Apacheが再起動されるまで、サイトは403Forbiddenエラーを返し始めます。 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#
その後、最後の3行は、サーバーに対して行われたすべての要求に対して繰り返されます。私はこれが起こらないようにする方法に本当に途方に暮れています。 prctlを使用して開くことができるファイルの数を増やしてみましたが、65.5Kに設定しようとすると、prctlが基本に対して1.02Kを返すため、正しく使用してはいけません。それが適切な解決策であるかどうかさえわかりません:
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 -
では、このような問題を追跡して修正するための最良の方法は何ですか?
更新
これは、ルートhttpdプロセスのpfileの出力です。
[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
これらのエラーが発生し始めたときに、最大接続数については言及していません。
次のようなツール/コマンドを使用できます。
ps -ef | grep Apache | wc -l
lsof -p <Apache pid>
netstat -anp | grep 80 | grep -i ESTABLISHED | wc -l
最初のコマンドは、システム上のApacheプロセスの数を示します。 2番目のコマンドは、Apacheプロセスが開いているファイル/接続の数を示します。もちろん、実際の値に置き換える必要があります。 3番目のコマンドは、確立された接続の数を示します。
私はかつて似たようなものに火傷を負ったことがあります。確認したいもう1つのことは、PHPもファイルを吸い上げていないことです。PHPがセッション情報をディスクに保存している場合、突然リクエストの過負荷は、すべてのファイルを吸い上げる可能性もあります。
あなたが良いメモリとCPUを持っているなら、あなたはnoを増やすことができます。 ulimitコマンドによる開かれたファイルの制限
ulimit -n 32667(これよりも高い場合があります)
「開いているファイルが多すぎます」というエラーは、誤った呼び方かもしれないと思います。 Solarisの土地の仮想メモリである/ 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" }'
誰かがこれをもっと雄弁に言うことができると確信していますが、それは私にとってはうまくいきます。 hth。
あなたが良いメモリとCPUを持っているなら、あなたはnoを増やすことができます。 ulimitコマンドによる開かれたファイルの制限
ulimit -n 32667(これよりも高い場合があります)
これは古い質問だと思いますが、別の質問では、問題に対して非常に適切な回答がありました。それがあなたにも当てはまるのではないかと思います。
https://superuser.com/a/829413/196842
基本的に、Xdebugは、デバッグクライアントが開いていないときに、接続リスナーのファイル記述子をリークしています(これが技術的に正しくない場合は申し訳ありませんが、それがアイデアです)。この問題を解決するには、リモートデバッガーがデバッグセッションを開始するときにデバッガークライアントが開いていることを確認します。もちろん、より良い解決策は、開発者によるバグの修正です。