Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

macOS: two per-conversation servers run duplicate full index_repository workers on the same repo simultaneously (~400% CPU each, respawning every few minutes) — per-repo worker serialization still missing (0.9.0)

オープン
  • 何か問題がありますか？
#2,673 コメント 3 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 2 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
バグ
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
c, macos, sqlite
領域
backend, databases, performance

調査の方向性

Start by reading #1083 for the existing per-repository coordination proposal, then trace the index_repository worker entry point and the code that quarantines corrupt databases (the issue names no source files or tests). Reproduce with two server instances indexing the same active repository and inspect the logs and database behavior. Done means workers for one repository are coordinated across instances and repeated full indexing or database corruption no longer occurs under this scenario.

索引モデルが issue の本文から書いたものです。

説明

awaiting-reporter bug editor/integration parsing/quality stability/performance
Environment
  • codebase-memory-mcp 0.9.0 (latest is v0.12.1 — happy to retest on it, but filing this as a macOS datapoint since the fix suggested in #1083 does not appear to have landed)
  • macOS 26 arm64 (Apple Silicon, 96 GB RAM)
  • Install channel: install.sh → ~/.local/bin/codebase-memory-mcp
  • Multiple concurrent MCP client sessions against the same repo (one long-lived CLI host), each conversation spawning its own codebase-memory-mcp server instance
  • Repo: ~2.2 GB worktree, ~18.5k source files, actively modified during the workday (build outputs + tool-generated temp files). build/ dirs are not git-ignored (partly on us).
What happened

The machine sat at load average ~55 with 0% idle CPU while essentially idle from the user's perspective. Two distinct server instances (two different MCP conversations) each spawned a full index_repository worker for the same repo at the same time:

PID 13629  456.9% CPU  cli --index-worker index_repository {"repo_path":"/Users/<user>/Projects/<repo>"}   (parent server 46586)
PID 14093  401.4% CPU  cli --index-worker index_repository {"repo_path":"/Users/<user>/Projects/<repo>"}   (parent server 66866)

And this is not a one-off: paired skip-report logs in ~/.cache/codebase-memory-mcp/logs/ show one full extraction run per server, roughly every 1–8 minutes while the worktree is being modified:

12:41, 12:42   (×2 files)
12:43, 12:44   (×2)
12:46          (×2)
12:49          (×2)
12:53          (×2)
12:59          (×2)
13:01          (×2)

Each run re-scans/re-parses the whole tree (each skip report lists the same parse timeouts, e.g. UFIPanel/iosport/**/build/**/Intermediates.noindex/*-primary.d — the .d-parsed-as-D issue from #2414) and burns 400%+ CPU for minutes. Net effect: CPU never gets a break.

Aggravator observed the same day: the project DB was quarantined as ~/.cache/codebase-memory-mcp/<repo>.db.corrupt (669 MB, 12:51 local), throwing away the whole graph and forcing a from-scratch rebuild. The cache dir currently holds 9 .db.corrupt files across projects (Jul → Oct). Suspect: concurrent multi-process SQLite writers with no per-repo coordination — same root as the WAL starvation in #1083.

Diagnosis

Same root pattern as #1083, macOS variant, CPU-flavored instead of WAL-flavored:

  1. No per-repo serialization of index workers across server instances — N conversations = N duplicate full indexes running concurrently.
  2. Staleness triggers a full re-extract, not an incremental update, and there is no debounce/backoff while the tree is churning (#1884) — on an active worktree the index is stale again before a rebuild finishes, so workers respawn forever.
  3. Corruption → silent discard → full rebuild (#391 family), which resets all progress and feeds loop #2.
Suggestions
  1. Implement #1083's suggestion 2 cross-platform: a per-repo file lock so a second index_repository queues or no-ops instead of running duplicate full indexes. Locking is not a Windows-only concern.
  2. Debounce/backoff re-index triggers on hot worktrees; consider incremental (mtime/hash) extraction instead of full re-parses (#1884).
  3. Harden DB writes against the recurring .db.corrupt quarantines; log a loud warning when it happens (users only find out via CPU).
Related issues
  • #1083 (per-conversation servers + 11 concurrent index workers, WAL starvation, Windows)
  • #2400 (multiple server processes), #45 / #1084 / #2093 (high CPU family)
  • #1884 (debounce artifact re-export), #391 (silent index corruption)
  • #2414 (.d dep-info files parsed with the D grammar — the exact parse timeouts in our skip reports)
  • #2649 (index_repository OOM)
主要言語
C
スター
45.8k
フォーク
3.8k
平均マージ
3日 4時間
マージ済み PR（30日）
208

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

DeusData/codebase-memory-mcp のほかの issue

DeusData/codebase-memory-mcp の issue をすべて見る

似ている issue

C の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。