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
とあるエラーの調査記録
Search
Satoshi Kaneyasu
August 27, 2023
Programming
0
410
とあるエラーの調査記録
Satoshi Kaneyasu
August 27, 2023
Tweet
Share
More Decks by Satoshi Kaneyasu
See All by Satoshi Kaneyasu
フルリモートで社内にどうやって自分の居場所を作るのか?
satoshi256kbyte
1
300
プロジェクトマネージャーがGitHub Copilotのエージェンモードを使い始めました
satoshi256kbyte
1
130
そもそもAWS Configの設定変えられたらどうするの?Amazon EventBridgeでマネコンの操作を監視する
satoshi256kbyte
1
110
変化の激しい時代における、こだわりのないエンジニアの強さ
satoshi256kbyte
1
1.6k
密集、ドキュメントのコロケーション with AWS Lambda
satoshi256kbyte
1
270
【PHP】破壊的バージョンアップと戦った話〜決断と説得
satoshi256kbyte
0
260
今更聞けないセキュリティ用語の基礎知識 2025新春
satoshi256kbyte
0
180
AWS re:Invent 2024個人的まとめ
satoshi256kbyte
0
320
今年一番支援させていただいたのは認証系サービスでした
satoshi256kbyte
1
610
Other Decks in Programming
See All in Programming
PipeCDのプラグイン化で目指すところ
warashi
1
280
dbt民主化とLLMによる開発ブースト ~ AI Readyな分析サイクルを目指して ~
yoshyum
3
1k
ISUCON研修おかわり会 講義スライド
arfes0e2b3c
1
450
Claude Code + Container Use と Cursor で作る ローカル並列開発環境のススメ / ccc local dev
kaelaela
10
5.2k
おやつのお供はお決まりですか?@WWDC25 Recap -Japan-\(region).swift
shingangan
0
140
なぜ「共通化」を考え、失敗を繰り返すのか
rinchoku
1
650
生成AI時代のコンポーネントライブラリの作り方
touyou
1
220
LT 2025-06-30: プロダクトエンジニアの役割
yamamotok
0
760
AIエージェントはこう育てる - GitHub Copilot Agentとチームの共進化サイクル
koboriakira
0
590
Azure AI Foundryではじめてのマルチエージェントワークフロー
seosoft
0
170
Quand Symfony, ApiPlatform, OpenAI et LangChain s'allient pour exploiter vos PDF : de la théorie à la production…
ahmedbhs123
0
190
プロダクト志向なエンジニアがもう一歩先の価値を目指すために意識したこと
nealle
0
130
Featured
See All Featured
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
A designer walks into a library…
pauljervisheath
207
24k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.5k
Art, The Web, and Tiny UX
lynnandtonic
299
21k
Become a Pro
speakerdeck
PRO
29
5.4k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
Fireside Chat
paigeccino
37
3.5k
StorybookのUI Testing Handbookを読んだ
zakiyama
30
5.9k
How GitHub (no longer) Works
holman
314
140k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.7k
A better future with KSS
kneath
238
17k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
251
21k
Transcript
とあるエラーの調査記録 2022.08.30 SATOSHI KANEYASU
はじめに • とあるプロジェクトにおける結合テストで起きたエラーの、 原因調査記録です • エラー調査の仕⽅は習ったことはありません、全て独学です • このことはあまり⼈に話す機会がないので、 今回テーマにしてみました。
⾃⼰紹介 • ⽒名︓兼安 聡 • 所属︓株式会社サーバーワークス • 趣味︓サックス、筋トレ、CS ゲーム •
資格︓ • X(Twitter)︓@satoshi256kbyte など
• 調査対象のエラーが発⽣したシステム • フロントエンド︓ jQuery(古い実装です) • バックエンド︓Amazon Linux、Apache、PHP(フレームワーク使⽤)、MySQL • 結合テスト中に⾒つかったエラーで、チケットで連絡が来たとします
• 画⾯上でとある操作をすると、予期せぬエラーが出たとします • エラーの最終的な原因は、意図せず⼤量データを取得した故の、 メモリ不⾜エラーとします • 複数の事象を混ぜた話なので、多少⽭盾があるかもしれません。 調査対象の条件
エラー調査とは、少しずつ範囲を狭めること こっちではエラー起きない まだわからない エラー起きない 調査済 まだわからない この辺り? 調査済 何も出てない エラー起きない
①エラーを再現する • 画⾯を操作して、現象が再現できることを確認 • ブラウザの開発ツールを確認 • Consoleタブで、JavaScriptエラーがないことを確認 • Networkタブで、エラーになっている通信があることを確認 •
この時点で、フロント側の問題ではないと推測 • エラーの通信を調べ、URL・リクエスト内容・レスポンス内容を確認 • レスポンス内容から、詳細不明だがやはりエラーを返してることを確認 • URLからPHP側のファイル・クラス・メソッドを⼤体特定 • リクエスト内容は控えておく
②WEBサーバーを調べる • フロント側の問題ではないとの判断から、サーバーの⽅を調査 • PHPのフレームワークのログに、 これといったログがないことを確認 • Apacheのログにて何かエラーが起きてることだけは確認 • OS・
PHP-FPMのログには特に何も⾒つからず • PHPのフレームワークのログをもう⼀度確認すると、 ログが途中で⽌まってるように⾒えることを確認 • この時点でチケットにここまでの調査内容を記⼊して周知 • ここまでで約1時間
[補⾜]RedHat系のログ出⼒先 • Apacheのログ︓/var/log/httpd配下 • PHP-FPMのログ︓/var/log/php-fpm配下 • OSのログ(システムログ)︓/var/log/message配下
③DBサーバーを調べる • ログが途中で⽌まってるように⾒えることから、 DBサーバー側の調査を開始(理由は次ページ) • 画⾯で現象を再現させ、その間のDBサーバーの挙動を確認 • SHOW PROCESSLIST コマンドで実⾏中SQLを確認
• DBサーバーのCPU・メモリなどを監視 • 監視結果から、⾮常に重たいSQLが⾛って完了してないことを確認 • おそらくSQLが終わらないことにより、処理がそこから進んでない、 それによりタイムアウトエラーが発⽣していると推測 • この時点で、ここまでの調査結果をチケットに記⼊して周知 • ここまでで約1時間半
[補⾜] DBサーバー側の調査を開始した理由 • SQLのログは、SQLが実⾏完了してから出⼒されることが多い。 • 従って、ログにSQLが出ていない=まだ実⾏中のSQLがある可能性が ⾼い • SQLは通るが、PHPが処理しきれてないのならば、PHP-FPMあたり に何かエラーが出るはずである
• なお、実⾏完了して初めてログが出るのはApacheのアクセスログも 同様で結構重要なこと
④重いSQLを発⾏している箇所の特定 • SHOW PROCESSLISTを使って控えたSQL、途中で⽌まったログか ら、ソースコード上のあたりをつける • 複雑でソースがさっと追いきれないので、あたりをつけた直前の⾏に ⼀時的にthrow new Exception();を⼊れる
• エラーが発⽣する操作を⾏うと、スタックトレースが出⼒されるので、 あたりは正解だと確信 • 最初に控えたURL・リクエスト内容から、⼊り⼝からソースを追い、 上記スタックトレースと付き合わせ特定した箇所が間違いないことを 確認
⑤修正案の作成 • 取り急ぎSQLのチューニングは決まり • SQLのチューニングしても、今度はPHPでエラーになる可能性がある ので、PHPの修正も視野に⼊れる 具体的には、⼀気にデータを受け取るのでなく、カーソルを使⽤する など • 上記修正に伴い、リグレッションテストが発⽣すると想定
• 以上をまとめてチケットに記⼊し、⼀旦調査完了とする 修正内容の具体的な設計は後⽇⾏う • ここまでで約2時間
⑥重いSQLの調査 • 後⽇調査再開 • 重いSQLが実際に返す件数、実⾏計画、メモリなどの動きを観察 • その結果、実⾏計画がよくない+件数が多すぎる+1レコードのデー タサイズが⼤きい、の合わせ技でメモリを⼤量消費していることが判 明 •
この部分のロジックを⾒直すことを提案。 • リスクもそれなりにあるので、どのように対応するか協議中。 以上。
[補⾜] エラーを共有する場合 • エラーメッセージ、エラーログ、スタックトレースの共有は、 ハードコピーも嬉しいが、テキストの⽅がより嬉しい • 理由は、エラーを検索したり、それを元にGREPしたりするから • ハードコピーだとそれらが⼿⼊⼒になる、エラー対応で余裕がない時 は、些細な⼿間で苦しくなってしまう
以上です。ありがとうございました。