epoll待機・送信キュー・セマフォの調査
職務経歴書の8エピソード一覧から、今回は一つだけ選ぶ。同じページの他の経験には広げず、関連知識の補強もこのエピソードに沿って行う。
セッション：DB製品の処理遅延を調査・検証
Section titled “セッション：DB製品の処理遅延を調査・検証”EC2上のDB製品の遅延について、straceと検証環境でepollの待機・通知を調べ、顧客への説明と改善案の提案につなげた経験。
https://github.com/MFQWKMR4/tech2026 のAGENTS.md、CHATGPT.md、src/content/docs/projects/epoll-investigation.md、reviews/experience-epoll-investigation.yaml、src/content/docs/career/interview-tips.md、.github/ISSUE_TEMPLATE/session-sync.md、reviewが参照する必要な過去sessionを読んでください。読めた資料とcommit SHAを示し、読めない場合は読んだとせずsession packを求めてください。今回はtopic: experience-epoll-investigation、session_type: experienceです。選択エピソード：DB製品の処理遅延を調査・検証。1エピソード1セッションとし、他の開始文は実行しないでください。対象：EC2上のDB製品の遅延について、straceと検証環境でepollの待機・通知を調べ、顧客への説明と改善案の提案につなげた経験。既存needs_revisitのうち今回の話に関係するものを優先し、無関係な項目は次回に残してください。なければ最初の一問は「顧客が困っていた遅延を、最初にどの観測から調べ始めましたか。」。一度に一問だけ尋ね、回答を待ってください。当時の課題・観測→自分の担当と行動→判断理由と代案→検証・結果を、回答に応じて思い出す手助けをしてください。覚えていない事実はunknownで止め、今知りたい仕組みを一つ選んで学び直してください。技術補強の候補：straceの時刻・待ち時間、epollの通知条件、送信側と受信側の待ちの区別、再現実験で否定できる範囲。前提知識を短く説明し、一次資料のURLと対象バージョンを示してから、条件を一つ変えた問いで理解を確かめてください。注意：DB内部の根本原因や改善案の効果は未確認です。元ノートの観測と、私自身が実施・説明した範囲を確かめてください。当時の経験、今の学び、AIの補足・演習条件を分け、経験・成果・不足を推測で補完しないでください。会社名・顧客情報・非公開情報・職務経歴書の連絡先は教材や同期Issueへ転載しないでください。最後に私自身がこのエピソードを短く説明し、根拠のある担当・判断・結果と、まだ確認が必要な点を整理します。模範回答を先に出さないでください。開始時刻が分かれば記録し、40分付近で区切りを提案。時刻不明なら経過を推測しないでください。終了時は既存形式の[Session Sync]（YAML＋Session narrative）を作成し、summaryとnarrativeに選択エピソード名、実際の回答・ヒント、当時の経験と今の学びを残してください。フィードバックではtipsから今回に関係する観点を選び、実際の回答を根拠に伝わった点・説明を補う点・未確認を分け、narrativeに残してください。全問の消化は目標にしません。repository_requestsにはこのprojectページへ戻す想起内容・技術解説を指定し、別エピソードの記録を上書きしないでください。Issueを作成できなければ未作成と明示し、コピーできるタイトルと本文を返してください。GitHubを読めない場合は npm run session:pack -- experience-epoll-investigation の出力を渡す。パック内に複数の開始文があっても、選択した一件だけを扱う。
このページの使い方
Section titled “このページの使い方”分散DBのSQL遅延を調べた経験を、当時何を考え、何を確かめたか思い出す入口にする。2026-09-14、Issue #16の代表ケースとしてObsidianノートから整理した初稿。対話はChatGPT、教材・記録の編集はCodexで行う。
以下は元ノートに残る記録の要約で、元の全ログや検証コードを再確認した実測報告ではない。本人への深掘りは未実施。会社名・顧客情報・内部ツール名を転載せず、観測、当時の解釈、現在の技術補足を分ける。
本人の経験：元ノートにあること
Section titled “本人の経験：元ノートにあること”問題と引き継ぎ
Section titled “問題と引き継ぎ”RHEL 8.10上の分散DBでSQL処理が通常より長くなっていた。ノートでは、DBベンダーの調査で recv() のEAGAIN後に epoll_wait() が数秒、長い場合は数分待つことが報告されている。
引き継ぎ前にはOSログ等の確認と、kernel.sem のSEMMNIがベンダーの最低要求値を満たさないという指摘があった。その後、本人は「Recv-Qの滞留とepoll待機に因果関係があるか」「Recv-Qが滞留する理由は何か」という問いを受けた。設定変更の実施・効果と、誰がどの解析を担当したかの詳細はunknown。
検証と観測の整理
Section titled “検証と観測の整理”| 段階 | ノートに残る行動・観測 | 当時の解釈と、残る確認 |
|---|---|---|
| 受信キューの検証 | 本人が検証環境を作り、Recv-Qにデータがある状態でepollがイベントを返すことを確認した | 受信キュー滞留だけで長時間待機を説明できるのか見直した。本番の登録イベント・LT/ET設定は未確認 |
| 送信側の検証 | 帯域不足についての追加質問を受け、送信キューが増えた状態でblocking sendが長時間待つことを確認した | 送信側の空き容量と待ちの関係を説明した。元ノートでは約11.6秒の待ちと短い送信結果が記載されるが、再現コード・全条件は未収録 |
| プロセス間の通知 | ある実行主体のsemop終了直後にUNIX domain socketへの1 byte送信があり、別の実行主体のepollがEPOLLINを返す並びが記録されていた。両方の待ちは約5.5秒 | ノートでは通知する側のセマフォ待ちがepollの待ちにつながると解釈。FDとsocketの対応をどう確定したか、他の長時間待機も同じ構造かは追加確認が必要 |
| ネットワークの観測 | CloudWatchとENAメトリクスを確認し、帯域上限への抵触を報告したと記載 | 時刻・集計期間・カウンタの増分・対象NICとSQL遅延の対応は未収録。セマフォ待ちまで同一原因で説明できたかはunknown |
ノートに記された認識の変化
Section titled “ノートに記された認識の変化”「キューが溜まるからepollが遅い」という説明を、そのまま採用せず検証したことが転機として書かれている。また、待っているsyscallだけでなく、その待ちを終わらせる通知を誰が送るかをPID・FD・時刻から追うことを学びとして挙げている。
ただし、ノートの「逆にepollが長引いたからRecv-Qが滞留した」という解釈まで確定したわけではない。どのsocketを、いつ、どのモードで監視していたかを揃えた証拠が必要である。
結果と担当範囲
Section titled “結果と担当範囲”ノートには、OSの挙動を検証して説明し、DBベンダーとの切り分けに使える情報と帯域上限への抵触を伝えた、とある。SQL遅延の最終解消、設定変更後の効果、DB内部のセマフォ待ちの根本原因はunknown。解決率や性能改善を本人の成果として補わない。
次の対話で思い出したいこと
Section titled “次の対話で思い出したいこと”以下は質問候補であり、評価済みの不足ではない。ChatGPTは会話に応じて一つずつ選ぶ。
- 引き継ぎ時の依頼範囲と、本人が最初に疑ったこと。
- 受信キューの検証で、何を固定し何を変えたか。どの結果なら初期仮説を支持・棄却できると考えたか。
- semopと通知のつながりに気づいた順序、PID/FDの対応を確かめた方法。
- 送信側の検証へ進んだ理由と、本番との違いをどう説明したか。
- 帯域上限とセマフォ待ちについて、どこまで言い切り、何をベンダーへ残したか。
- 最終回答の後に分かったこと、今なら追加で観測したいこと。
AIによる技術補足：必要になったときに読む
Section titled “AIによる技術補足：必要になったときに読む”epollとキューを結び付ける前提
Section titled “epollとキューを結び付ける前提”FDはプロセスがI/O対象を参照する番号。epollは登録したFDのI/O可能性を通知する。長い待機時間だけではepoll実装の不具合とは言えない。
LTでは読み取り可能な状態が続く間、通知対象になる。一方ETではデータを読み残していても次の変化まで待ち得る。ONESHOTの再登録や他のreaderも確認する。本番がLTだったという元ノートの推測は、設定確認の代わりにしない。epoll(7)。
EAGAINと送信待ちを分ける
Section titled “EAGAINと送信待ちを分ける”nonblocking recvのEAGAINは、その時点で受信操作を進められないことを示す。semtimedopのEAGAINはタイムアウト、またはIPC_NOWAIT付き操作をすぐ実行できない場合などに起こる。同じerrnoから同じ原因を推定しない。SEMMNIの要求値不足と、既存セマフォの待ちとの因果は別途確認が必要。recv(2)、semop(2)。
送信バッファに余地がなければblocking sendは待ち得る。nonblockingではEAGAIN等となり、部分送信も扱う必要がある。待つ実装は単純だが、イベントループの同じ実行主体で待てば他の仕事を進められない。非同期化は待ちを扱いやすくする一方、未送信データや再開処理の管理が必要になる。send(2)。
TCPのACKは受信アプリがデータを読み終えた証明ではない。「受信アプリが遅いからACKしない」と直結させず、受信バッファと広告window、未ACKデータ、再送などを分ける。送信キューが大きいだけで帯域不足を確定しない。tcp(7)。
ENAから言えること
Section titled “ENAから言えること”bw_in_allowance_exceeded / bw_out_allowance_exceeded は、それぞれ方向別の帯域上限超過によりキューイングまたはドロップされたパケット数。対象時間の増分を見る。ENAメトリクスはCloudWatch agent経由でも公開できるため、「CloudWatchでは取得できない」とはしない。ネットワーク上限の観測と、特定SQLやセマフォ待ちの原因確定を分ける。AWS ENA監視。
今ならどう調べ、設計するか
Section titled “今ならどう調べ、設計するか”過去の記憶が埋まらなくても、今知りたい仕組みを一つ選んでよい。以下は現在の学習候補で、当時の実績や評価済みの不足ではない。
- 観測：長いsyscallを見つけた後、通知元の待ち・イベント登録・時刻をどう揃えて因果を確かめるか。
- 仕組み：LT/ETで同じ受信キューを見たとき、読み残しと次の通知の関係はどう変わるか。
- 設計：送信待ちをイベントループから外すなら、未送信データの上限と相手が遅い場合のbackpressureをどう扱うか。
- 運用：帯域制限への抵触を見つけても増強だけで終えず、処理の並列度・送信量・待ちの場所をどう比較するか。
ChatGPTでは必要な説明の後、一条件を変えた例で理解を確認する。その回答は「今学んだこと」として残し、当時できていたことへ書き換えない。他の調査ケース・容量計画へ接続する。
出典・対象環境・次の更新
Section titled “出典・対象環境・次の更新”- 経験の元資料：ローカルObsidianの
epoll_wait_sendq_semaphore_investigation.md。2026-09-14参照。原文は変更していない。 - ノート記載の環境：RHEL 8.10。kernelの正確なrelease、DB・strace・ENA driverのバージョンはunknown。
- 技術補足：上記Linux man-pagesとAWS公式文書を2026-09-14確認。Web版の一般仕様であり、RHEL 8.10固有のバックポートや当時のDB実装を検証したものではない。AWS文書は固定バージョンなし。
- Systems Performanceの入口 · 経験一覧
- 深掘りsessionは未登録。ChatGPTのSession Syncを受け、実際の回答・ヒントとともにこのページを更新する。