php-fpmのプロセスをコントロールする

Transcript

1. php-fpmのプロセスをコントロールする
2. 自己紹介 • 堂薗　伸樹（どうぞの　のぶき） • スターフェスティバル株式会社 • エンジニア • 38歳、妻、子2人、犬 DPon https://twitter.com/DPontaro
3. 今回お話すること • 既存WebアプリケーションにNew Relic入れることになった
 • 本番導入したらパフォーマンス悪くなり障害発生、切り戻し
 • 改めて検証
 • php-fpmとNew Relicのパラメータ調整して無事導入
4. New Relic 
 
 アプリケーションパフォーマンス管理(APM)ツール。
 Webアプリケーションやサーバーのパフォーマンスを可視化。
 開発者はシステムの問題を迅速に特定し、改善することができるようになる。
5. php-fpm 
 
 
 FPM (FastCGI Process Manager)
 CGIはリクエスト毎にプロセスの生成、破棄が行われるのでリクエスト数の増大によりそのオーバーヘッドが無視でき なくなる。
 
 php-fpmでは起動時にプロセスをメモリ上に保持（プール）し、リクエスト毎にプロセスを再利用するためオーバーヘッ ドなく処理できる
 今回お話するアプリケーションは、nginx + php-fpmで実装、AWSでECSクラスター上で稼働している。

6. New Relic導入 社内で各アプリケーションへの導入が進んでおり私が担当していたアプリケーションにも導入することに。
 が、本番導入した際パフォーマンスに影響が出てしまい、切り戻し。 
 New Relicというツールの特性上、実行されてるコードのトレースが行われる。
 →そのあたりが影響した可能性が高そう。

7. 検証 New Relicを入れたECSクラスターを別途用意。
 n%だけそちらに割り振られるようにALBのリスナールールを設定して検証を進めることに。
 
 

8. いざモニタリング New Relicを導入したコンテナのCPU使用率 ALBのリクエスト数
9. 発生していたwarning WARNING: [pool www] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 32 children, there are 0 idle, and 9 total children リクエスト量が生成済のプロセス数を上回って処理できていなかった。 生成済のプロセスは9個、うちアイドル状態のものが 0、別途32個のプロセスを生成しようとしている状態。
10. プロセス数を制御する dynamic -> staticに変更。 起動時からmax_children分のプロセスを生成するように調整して再度検証。 pm = dynamic pm.max_children = 40 pm.start_servers = 2 pm.min_spare_servers = 1 pm.max_spare_servers = 3 pm = static pm.max_children = 40 # 以下はstatic時には意味をなさなくなる pm.start_servers = 2 pm.min_spare_servers = 1 pm.max_spare_servers = 3
11. プロセスの再起動を制御する 引き上げて再起動のタイミングがうまくバラけた pm.max_requests = 500 pm.max_requests = 5000 pm.max_requestsはプロセス毎に設定したリクエスト数をさばくとプロセスの再起動がかかる プロセス毎の再起動までのリクエスト数が小さく、近しいタイミングでプロセスの再起動が起きたのではないか またCPU使用率があがった。 同様のタイミングでメモリがガクッと空いていた（キャプチャ漏れ） php-fpmのプロセスの再起動が一気に起きた可能性と推測。
12. NewRelicのパラメータもちょいと調整 1分あたりにNew Relicに送信されるイベント量の設定。デフォルトは 2000。 引き下げてレスポンスタイムも改善。 newrelic.span_events.max_samples_stored = 1000 リクエストは捌けるようになり CPU使用率は問題なくなったが、レスポンスタイムが導入前より 50~100msほど 上昇傾向。
13. それぞれのデメリット pm = static
 • リクエストが少ないときはアイドル状態のプロセスが多くあり、余分にメモリを使用する
 ◦ 今回メモリは余裕があったのでdynamicにしておく意義は薄いと判断
 pm.max_requests
 • 値を引き上げるとプロセスが長生きする分、メモリ使用量への影響が出てくる
 ◦ 今回対応したアプリケーションではリソース的に問題ない範囲の引き上げ
 newrelic.span_events.max_samples_stored
 • 減らした分、サンプルは少なくなり分析に支障が出るかもしれない
 ◦ 今回減らした分は分析には支障ない範囲での引き下げ

14. ご清聴ありがとうございました