2013-12-23 11 views
5

サーバーのCPUスパイクは30分間隔で表示されています。これは、セッションファイルをクリーンアップするphp5ジョブによって引き起こされた可能性があります。これは、サーバー上の私たちの/etc/cron.d/php5から取られる:過去のリリースでは、このジョブで問題となっているように思わfuserプロセスCPU使用量が多いphp5 cronジョブ

# /etc/cron.d/php5: crontab fragment for php5 
# This purges session files older than X, where X is defined in seconds 
# as the largest value of session.gc_maxlifetime from all your php.ini 
# files, or 24 minutes if not defined. See /usr/lib/php5/maxlifetime 

# Look for and purge old sessions every 30 minutes 
09,39 *  * * *  root [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -ignore_readdir_race -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2>/dev/null \; -delete 

。 Ubuntuのバージョン11.10には問題がありましたが、これは大量のCPUを使用していましたが、UbuntuとPHPの両方のビルドをはるかに実行しています。 PHPのこの仕事はどれくらい重要ですか?私たちは、この仕事の実行を停止するか、優先順位を下げることができますか?

+0

CPUがスパイクしているからといって、必ずしも何らかの懸念があるわけではありません。ファイルは、ある時点でクリーンアップする必要があります。クリーンアップするには、できるだけ早くクリーンナップし、使用可能なリソースを使用して作業を完了させる必要があります。あなたはこの仕事がサーバーに不当に課税していると言っていますか? – deceze

+0

それはリソースをうまく使っているかもしれませんが、問題はこのジョブが完了するのに2分かかってしまい、ラッシュアワー時に余分なCPU使用量があれば、その時間にリクエストに応答できなくなることです。 – user2708100

答えて

0

findとfuserを使ってファイルシステムを繰り返して再帰的にスクラッチするのは悪い考えです。

セッションをファイルに保存しないようにしてください。まだ完了していない場合は、すぐにこれと他の多くの問題を取り除いてください。実際にセッションでファイルストレージを使用していない場合は、その行を削除するかコメントアウトしてください。

3

これはバグで、pmiscパッケージに反映されているようですが、php5-apcが機能している場合はphp5の一部でもあります。
そこUbuntuのバグ報告があり、ここに述べたworkaroud提案: https://bugs.launchpad.net/ubuntu/+source/php5/+bug/876387

09,39 * * * * root [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) -delete 

、ここでDebianのバグレポートを: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633100

私は喘鳴のDebian上での回避策をテストしてきたし、それが動作し、更新するものの、パッケージはより良いでしょう!

関連する問題