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
今ならAmazon ECSのサービス間通信をどう選ぶか / Selection of ECS Interservice Communication 2025
tkikuc
21
4k
PipeCDのプラグイン化で目指すところ
warashi
1
280
5つのアンチパターンから学ぶLT設計
narihara
1
170
Rubyでやりたい駆動開発 / Ruby driven development
chobishiba
1
730
Startups on Rails in Past, Present and Future–Irina Nazarova, RailsConf 2025
irinanazarova
0
110
技術同人誌をMCP Serverにしてみた
74th
1
650
20250628_非エンジニアがバイブコーディングしてみた
ponponmikankan
0
690
PostgreSQLのRow Level SecurityをPHPのORMで扱う Eloquent vs Doctrine #phpcon #track2
77web
2
530
20250704_教育事業におけるアジャイルなデータ基盤構築
hanon52_
5
790
効率的な開発手段として VRTを活用する
ishkawa
0
140
#kanrk08 / 公開版 PicoRubyとマイコンでの自作トレーニング計測装置を用いたワークアウトの理想と現実
bash0c7
1
770
Team operations that are not burdened by SRE
kazatohiei
1
310
Featured
See All Featured
We Have a Design System, Now What?
morganepeng
53
7.7k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
950
Documentation Writing (for coders)
carmenintech
72
4.9k
Visualizing Your Data: Incorporating Mongo into Loggly Infrastructure
mongodb
46
9.6k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3.1k
The Art of Programming - Codeland 2020
erikaheidi
54
13k
Code Review Best Practice
trishagee
69
18k
Embracing the Ebb and Flow
colly
86
4.7k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
34
5.9k
Optimising Largest Contentful Paint
csswizardry
37
3.3k
The Pragmatic Product Professional
lauravandoore
35
6.7k
What’s in a name? Adding method to the madness
productmarketing
PRO
23
3.5k
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したりするから • ハードコピーだとそれらが⼿⼊⼒になる、エラー対応で余裕がない時 は、些細な⼿間で苦しくなってしまう
以上です。ありがとうございました。