Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
php-fpmのプロセスが枯渇した日-調査・対処・そして本当にやるべきだったこと-
Search
にわ
July 19, 2026
Programming
290
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
php-fpmのプロセスが枯渇した日-調査・対処・そして本当にやるべきだったこと-
PHP Conference 2026 LT 登壇資料
にわ
July 19, 2026
More Decks by にわ
See All by にわ
「値はあるのに空判定」される怪奇現象を追ったら、犯人は __isset だった話 / PHPerKaigi 2026 ルーキーズLT
shibuchaaaan
0
74
Other Decks in Programming
See All in Programming
夏だ!祭りだ!祭りとはドメインモデリングでは?
ryugen04
0
290
freee が目指す データ マネジメント戦略 AI-Ready 時代を支える 攻めのガバナンスとは
freee
PRO
0
380
為什麼你並不需要ViewModel / No, you don't need a ViewModel
lovee
1
500
AI Readyの正体はデータマネジメントだ メダリオン2.0の最前線
freee
PRO
0
250
5分で問診!Composer セキュリティ健康診断
codmoninc
0
1k
yield再入門 #phpcon
o0h
PRO
0
1.1k
Android CLI
fornewid
0
220
いまどきの Codex で開発する visionOS アプリの開発スタイルについて
karad
0
140
Terraform標準の組織で AWS CDKをどう使うか
mu7889yoon
1
520
【やさしく解説 設計編・中級 #6】良いアーキテクチャとは ~ 一本の登り道の、行き先 ~
panda728
PRO
0
210
AWS CDK を「作」ってみた 〜フルスクラッチで見えた CDK の裏側〜 / aws-cdk-from-scratch
gotok365
3
2.8k
複数の Claude Code が"放置"されてしまう問題をCLI ダッシュボードを自作して解決した話
sumihiro3
1
680
Featured
See All Featured
Site-Speed That Sticks
csswizardry
13
1.4k
A Guide to Academic Writing Using Generative AI - A Workshop
ks91
PRO
1
370
WENDY [Excerpt]
tessaabrams
11
39k
Why Your Marketing Sucks and What You Can Do About It - Sophie Logan
marketingsoph
0
380
[Rails World 2023 - Day 1 Closing Keynote] - The Magic of Rails
eileencodes
38
3k
[SF Ruby Conf 2025] Rails X
palkan
2
1.3k
End of SEO as We Know It (SMX Advanced Version)
ipullrank
3
4.4k
Become a Pro
speakerdeck
PRO
31
6.2k
Game over? The fight for quality and originality in the time of robots
wayneb77
1
240
B2B Lead Gen: Tactics, Traps & Triumph
marketingsoph
0
200
AI Search: Where Are We & What Can We Do About It?
aleyda
0
7.8k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
201
75k
Transcript
php-fpmのプロセスが枯渇した日 〜調査・対処・ そして本当にやるべきだったこと〜 にわ @PHP Conference 2026
自己紹介 丹羽美希(にわみき) 趣味 お酒、バンド、バイクが好き ベース弾いてます 仕事 ユースタイルラボラトリー (ちょっと古い) 社内システム開発担当
504 Gateway Timeout 3
500エラーとかじゃないから、 PHPの処理に到達する以前に apacheが死んでるのでは? 4
apacheが死んでた ↓ とりあえずシステム復旧のた めapache再起動 5
apacheが亡くなった現場 // まずは直近のapacheエラーログ確認 $ tail -n 50 /var/log/httpd/error_log … [mpm_event:error]
[pid 3417425:tid 139922572937536] AH03490: scoreboard is full, not at MaxRequestWorkers.Increase ServerLimit. 6
FastCGI Process Manager 7
php-fpmは 「PHPの実行エンジン」 プロセス リクエスト
php-fpmの状況確認 $ ps aux | grep 'php-fpm' apache 2487148 2.1
3.7 821056 67984 ? S 15:37 0:20 php-fpm: pool www apache 2487155 1.4 3.6 745496 66868 ? S 15:38 0:13 php-fpm: pool www apache 2487223 1.5 4.3 757628 79476 ? S 15:38 0:14 php-fpm: pool www …(いっぱい) // 数を確認 $ ps aux | grep php-fpm | wc -l 22 9
php-fpmのプロセス数設定 $ grep "pm.max_children" /etc/php-fpm.d/www.conf pm.max_children = 20 10
php-fpmのプロセス上限 行っちゃってる!!! 11
php-fpm のエラーログを確認 $ tail /var/log/php-fpm/error.log [WARNING] pool www: server reached
pm.max_children setting (20), consider raising it 12
①プロセス数増やせば 解決やん! 13
pm.max_children設定数の考え方 pm.max_children = サーバーの利用可能メモリ ÷ 平均的な PHPプロセスのメモリ使用量 14
サーバーの利用可能メモリ $ free -m total used free Mem: 1774 407
275 Swap: 2047 483 1564 shared buff/cache available 134 1091 1056 15
PHPプロセスのメモリ使用量平均 $ ps aux | grep 'php-fpm' apache 2499211 6.7
4.4 754848 80760 ? S 17:25 0:27 php-fpm: pool www apache 2499212 5.7 3.5 811144 64740 ? S 17:25 0:23 php-fpm: pool www apache 2499354 4.4 3.2 736460 58424 ? S 17:27 0:12 php-fpm: pool www apache 2499426 3.7 4.1 821104 74896 ? S 17:28 0:08 php-fpm: pool www apache 2499497 3.5 3.4 810872 62064 ? S 17:29 0:06 php-fpm: pool www 16
1056MB / 68.1768MB = 15.48914プロセス 分使える 17
②そもそもなんで プロセスこんな溜まったん? ↓ phpの処理が遅いのが問題? 18
めっちゃ session_start()あるけど何!? [07-Jan-2026 15:39:58] [pool www] pid 2487291 script_filename =
/project/XXX.php [0x00007fd1f0013410] session_start() /project/config.php:22 [07-Jan-2026 15:39:58] [pool www] pid 2487294 script_filename = /project/YYY.php [0x00007fd1f0013410] session_start() /project/config.php:22 … 19
session_start()が遅くなった原因 1. 2. 3. 4. 重いSQL処理がプロセスを長時間占有 重い処理がセッションを掴んだまま走り続ける 後続リクエストが session_start() でロック解除待ちに連鎖
30個のプロセスがすべて「待ち」で埋まる → Swapまで使い果たしてフリーズ 20
どうすべきだったのか? 正しいプロセス数を設定 プロセスを詰まらせない設計 • メモリ計算なしに数値を増や • 重いSQLのチューニング すのは危険 • 重い処理もチューニング!
• 利用可能メモリ ÷ 1プロセス 非同期化するのも手 のメモリ使用量 • まず実測 21
まとめ 1. WebのPHPはphp-fpmくんが動かしてくれている (他の場合もある) 2. 実測と適切な設定をしましょう! 3. プロセスを詰まらせない設計が、安定稼働の根本 22
ご清聴ありがとうございました!