解決策 1:
人気のある Web サイトを所有し、それを仮想マシン上で常に実行し続けることができて、おめでとうございます。
本当に 1 日あたり 200 万のページビューを取得している場合は、ファイルシステムに大量の PHP セッションを積み上げることになり、 fuser または rm または掃除機。
この時点で、セッションを保存する別の方法を検討することをお勧めします:
- 1 つのオプションは、セッションを
memcachedに保存することです .これは超高速ですが、サーバーがクラッシュまたは再起動すると、すべてのセッションが失われ、全員がログアウトされます。 - セッションをデータベースに保存することもできます。これは memcached よりも少し遅くなりますが、データベースは永続的であり、単純な SQL クエリで古いセッションをクリアできます。ただし、これを実装するには、カスタム セッション ハンドラを作成する必要があります。
解決策 2:
fuser の削除 助けるべきです。このジョブは fuser を実行します 見つかったすべてのセッション ファイルに対してコマンド (ファイルが現在開いているかどうかを確認する) を実行します。これは、14k セッションのビジー状態のシステムでは簡単に数分かかることがあります。これは Debian のバグでした (Ubuntu は Debian ベースです)。
memcached の代わりに、セッション ファイルに tmpfs (メモリ内のファイル システム) を使用することもできます。 memcached と同様に、再起動時にセッションが無効になります (これは、シャットダウン スクリプトのどこかにこのディレクトリをバックアップし、起動スクリプトで復元することで回避できます) が、セットアップははるかに簡単になります。しかし、fuser では役に立ちません。 問題。
解決策 3:
したがって、ここでユーザーが提案する Memcached とデータベース セッション ストレージのオプションはどちらも、パフォーマンスを向上させるための優れた選択肢であり、それぞれに利点と欠点があります。
しかし、パフォーマンス テストによって、このセッション メンテナンスの莫大なパフォーマンス コストは、ほぼ完全に fuser の呼び出しにかかっていることがわかりました。 cronジョブで。 rm を使用する Natty / Oneiric cron ジョブに戻した後のパフォーマンス グラフを次に示します。 fuser の代わりに 古いセッションをトリムするために、切り替えは 2:30 に行われます。
Ubuntu の PHP セッション クリーニングによる定期的なパフォーマンスの低下がほぼ完全に解消されていることがわかります。ディスク オペレーション グラフに表示されるスパイクは、以前はサーバーのパフォーマンスが 25 分間大幅に低下していた小さな短い中断を示しており、大きさがはるかに小さくなり、このグラフで測定できるほど細くなっています。余分な CPU 使用率が完全になくなり、これは IO バウンド ジョブになりました。
(無関係な IO ジョブが 05:00 に実行され、CPU ジョブが 7:40 に実行され、どちらもこれらのグラフで独自のスパイクを引き起こします)
現在実行中の変更された cron ジョブは次のとおりです:
09 * * * * 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) -print0 \
| xargs -n 200 -r -0 rm