Goとfutex：待ち時間とCPU時間を分ける

このページの使い方

当時の判断を思い出すことを入口に、今の自分の知識を更新する。思い出せない事実はunknownのまま、必要な仕組みを学び直してよい。 対話はChatGPT、編集と同期はCodexで行う。ケース一覧から別のケースも選べる。

2026-09-14、Issue #16としてObsidianの Untitled. から整理した初稿。元ノートの要約であり、全ログ・コードの独立確認や今回の再実験ではない。実際の学習sessionはまだない。原文の観測と解釈、AIによる補足を分ける。

ChatGPTで振り返り、知識を更新する

ChatGPT開始文

https://github.com/MFQWKMR4/tech2026 を参照してください。
AGENTS.md、CHATGPT.md、src/content/docs/career/index.md、
src/content/docs/projects/go-futex-investigation.md、reviews/experience-go-futex.yaml、
.github/ISSUE_TEMPLATE/session-sync.mdと、reviewが参照する必要なsessionを読んでください。
読めたファイルとcommit SHAを示し、読めなければ読んだとせずsession packを求めてください。
今回はsession_type: experience、topic: experience-go-futexです。
当時の状況・担当・判断を一問ずつ聞いて回答を待ち、記憶を埋めるだけで終えず、必要な仕組みを学び直す時間も取ってください。
最初は「起動が遅いインスタンスと正常なものを、最初はどの情報で比較しましたか？」と聞いてください。
元ノートの記載、当時の解釈、今回の記憶、自力の説明、AIの補足、今なら考える案を区別してください。
過去の結論を正解と固定せず、必要な箇所で一次資料と対象バージョンを確認し、日本語で説明してください。
不明な用語や前提を一つずつ説明し、理由・trade-off・例外・運用・切り分けへつないでください。
説明後は条件を少し変えた短い問いで現在の理解を確認し、解説後の回答であることを記録してください。
変更条件は「演習上の追加条件」と明示し、当時の事実へ混ぜないでください。
記憶を深掘りできない場合や私が仕組みを知りたい場合は、過去の確認に留まらず今の疑問へ進んでください。
技術の説明だけから過去の担当能力・実績を評価せず、経験の確認と現在の理解をsummaryでも分けてください。
全節や全質問を一回で消化せず、一つの仕組みを深めてください。模範の経験談を先に作らないでください。
思い出せない実務事実はunknownのまま残し、未質問を不足や忘却と判定しないでください。
会社名・顧客名・識別情報・非公開の社内情報は記録しないでください。
開始時刻を確認できれば記録し、40分付近で区切りを提案。時刻不明なら推測しないでください。
終了時は実際の問い・回答・ヒント・理解の変化・未確認事項をYAML＋Session narrativeへまとめ、
MFQWKMR4/tech2026に[Session Sync] Issueを作り、URLを返してください。
repository_requestsには、このページへ戻す経緯・新しい技術解説・再確認したい問いを記載してください。
元ノートや教材作成を私の学習evidenceにせず、今回の回答を根拠にしてください。
Issue作成機能が使えなければ未作成と明示し、コピーできるタイトルと本文を返してください。

【求人との接点を意識した深掘り】
以下は2026-09-14に私が提示した求人の観点です。求人の最新性や、私が要件を満たすことを確認済みとは扱わないでください。
必須：バックエンドWebアプリ開発、REST APIの設計・実装、チームでの技術検討と開発、クラウド／サーバー基盤の基礎知識。
歓迎：高頻度・高負荷アクセスへのスケーラブルな設計・開発・運用、RDBMS／KVSの利用・最適化・運用、LB／CDNによる高可用性、HTTP/HTTPSの仕様理解。
歓迎：AWS／Google Cloudの構築・開発、ECS(Fargate)／Cloud Run等のコンテナ運用、ALB・Lambda・SQS・DynamoDB等を組み合わせる設計。
歓迎：長期運用と機能拡張を見据えた保守性、テスト・CI/CD、DDD、認証・認可・セキュリティ、OIDC／OAuth 2.0、TLS・暗号・署名検証。
歓迎：ゲーム専用機／IoT機器向けAPI、WebRTC、分散システムの開発。
人物像：課題の本質を追い最後まで取り組む、長期運用を考え抜く、新技術を楽しみ挑戦する、クライアント／企画まで視野を広げる、複雑な課題を正しく言語化し周囲を尊重して協働する、利用者視点でチームと課題を解く。

既存needs_revisitを優先しつつ、このケースと回答に関係する観点を1〜2個選び、一問ずつ掘り下げてください。全項目をチェックリストのように消化しないでください。
「どの課題・利用者影響があったか → 自分の担当・行動 → 判断の理由と代案 → チーム内の検討・合意 → 検証・運用結果 → 今なら変えること」を、回答に応じて確認してください。
私が実施した設計・実装、運用・調査、現在理解している知識、未経験／未確認を分けてください。規模・期間・成果の数値は回答に根拠がある場合だけ使ってください。
技術名が登場しただけで経験ありとせず、求人項目を自動でgap・needs_revisit・学習evidenceにしないでください。歓迎要件をすべて経験している前提で質問しないでください。
当時の情報が足りなければunknownを残し、今知りたい仕組みは一次資料で補足して理解を更新してください。解説後の回答を当時の能力へ書き換えないでください。
実際の回答が集まったら、まず私自身に面接で話す短い説明を試してもらい、その後で根拠のある経験と求人との接点、追加確認が必要な点を整理してください。合否や数値スコアは付けないでください。
Session Syncのsummaryとnarrativeには、扱った求人観点と回答根拠、当時の経験／今の学びの区別を残してください。repository_requestsにはページへ戻す補足を記載してください。
このケースで優先する候補：負荷と並行処理、クラウド／OSの理解、再現条件の検討、粘り強い調査と技術的な協働。ランタイムの調査をGoアプリの開発実績へ置き換えないでください。

GitHubを読めない場合はCodexで npm run session:pack -- experience-go-futex を実行し、出力を渡す。ChatGPTがローカルVaultを読めることは前提にしない。

本人の経験：元ノートにあること

問題と調査の経緯

一部のEC2インスタンスでGoアプリの起動が約20秒から数百秒へ延びた。ノートではm8i.4xlarge、Amazon Linux 2023、kernel 6.12.40と記録される。同型でも正常な個体があり、Goの正確な版、バイナリ・設定が同一だったかの確認結果はunknown。

段階	ノートの観測・行動	当時の判断と残る確認
正常系との比較	topでsystem CPUの差を確認し、strace統計を依頼	kernel側の処理を調べる入口。CPUの差だけでは待ちの原因を確定できない
futexへ着目	統計上futexが約94%を占め、FUTEX_WAIT_PRIVATEが繰り返される	元ノートはmutex競合を原因と解釈。集計オプション・時間の意味とユーザー側stackは追加確認が必要
ホストの仮説を更新	最初は同じホストへの集中を疑ったが、別ホストでも再現した	単一ホスト固有という説明を見直した。同じ世代のCPUが原因と確定したわけではない
再現条件を探る	Cのpthread_mutexテストでは顕著な差なし。Goではfutex頻度増加を記録。perfに待機からscheduleへ至るstack	呼出し回数増加と本番の起動遅延の再現は別。Go側テストが同じ性能異常を再現したかはunknown
次の調査へ	正常・異常比較を整理し、CPU/NUMA・時系列データの追加収集とエスカレーション。別タイプの利用を案内	切り分け情報と回避案を提示。最終的な原因確定・修正・回避策適用後の結果は未記録

ノートに残る学び

単発のtopだけでなく正常・異常の時系列を早く確保したかった、と記されている。特定ホストへの集中という初期仮説を追加データで更新し、自前テストの限界も踏まえて次の観測を依頼した経緯が核になる。本人の具体的な担当範囲・各判断の順序は対話で埋める。

AIによる技術補足：今の理解を更新する

Default / Why：futexは待つ場所を見せる

futexはユーザー空間の同期処理を支えるkernelの待機・起床機能。待機は値を比較してから行い、値が期待と違えばEAGAINとなり得る。したがってEAGAINの件数だけでアプリ障害や激しい競合を断定しない。mutexだけでなく、ランタイム内の同期にも使われる。futex(2)。

観測の読み直し：94%は何の割合か

straceの -c は原則system CPU時間の集計、-w 併用は呼出し開始から終了までの経過時間。-T は個々の呼出しの経過時間を示す。-f の統計は複数実行主体を合算する。元のコマンド、版、出力列を確認せずに「起動時間の94%をmutex待ちで消費」と言い換えない。トレース自体の負荷も比較条件に含める。strace(1)。

GoとOSをつなぐ

goroutine数、OS thread数、同時にGoコードを実行できるCPU数は別物。GOMAXPROCSは最後の並列実行を制限し、総OS thread数の上限そのものではない。元ノートの「GOMAXPROCSでスレッド数が制御される」はこの区別で補う。現行の既定値はCPU affinityやLinux cgroup quotaにも依存し、古いGoの挙動をそのまま当てはめない。Go runtime（確認時go1.27.1。本件のGo版はunknown）。

Trade-off / Production / Troubleshooting

今なら、CPU profileが示す実行箇所と、block/mutex profileが示す同期上の待ちを使い分ける。Go runtimeはblock/mutexの計測率を設定する機能を提供するが、計測の負荷と捕捉範囲を確認する。kernelのschedule stackだけから、どのアプリのlockを誰が長く保持したかは分からない。Go runtimeの計測機能。

GOMAXPROCSや同時実行数を下げる案は、競合を減らす可能性と並列処理能力を下げる可能性の両方がある。別インスタンスで速くなることも、CPU世代だけの因果証明ではない。同じバイナリ・負荷・起動段階・CPU割当を揃え、一条件ずつ比べる。再現しないテストは「この条件では確認できなかった」と残す。

次の対話：当時から今へ

• 当時：futexに着目した根拠と、mutex競合だと考えた追加情報は何だったか。
• 仕組み：CPUを使う時間、実行可能だがCPUを得られない時間、同期条件を待つ時間をどう分けるか。
• 今なら：正常・異常のどちらにも同じ計測をするなら、最初に何を取得するか。
• 設計判断：起動処理の並列化を減らす案と、lockの保持範囲を減らす案をどう比較するか。

面接では「原因を断定した」より、比較条件・反証・再現の限界をどう整理したかを本人の回答から確認する。Systems Performanceの入口・epollの通知待ちと接続する。

出典・対象環境

元ノートの環境はAL2023 / kernel 6.12.40。Go、strace、perfの正確な版はunknown。一次資料は2026-09-14にfutex(2)、strace(1)のWeb版とGo runtime go1.27.1を確認した。当時のツールに現行オプションがあるかは実環境で照合する。新しい性能計測は行っていない。

セッションと次の更新

元資料の参照は2026-09-14。原文は変更せず、顧客情報・内部情報を転載していない。本人の独力回答や深掘りsessionは未登録。質問候補と補足は学習済みの証拠ではない。ChatGPTのSession Sync後に、当時の経緯と今の理解の変化を区別して追記する。