Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[Perf] Linux: Grok sessions walk /proc every 25 ms on the server event loop, although the cgroup lease already handles teardown

Aperta Adatta ai principianti
  • Qualcosa non va?
#23,393 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
78/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
linux, typescript
Ambito
backend, performance

Direzione di ricerca

Inizia in packages/provider-acp/src/server/AcpSessionRuntime.ts, nella configurazione del lease cgroup e dell’observer continuo dell’ownership. Controlla i rami di teardown per confermare che il ledger dell’ownership venga usato solo senza un lease, quindi aggiungi o aggiorna il test con il controller di conteggio descritto nell’issue. Il lavoro è completato quando l’observer acquisisce la root una volta sotto un lease, il polling in idle si interrompe e la chiusura della sessione svuota il lease.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

The problem

On Linux, when a Grok session has a cgroup v2 lease (t3-acp-*, the normal case under systemd),
AcpSessionRuntime still runs observePosixOwnershipLedgerContinuously for the whole life of the
session. Every 25 ms it walks the agent's process tree in /proc on the server's main thread. Its
result (the ownership ledger) is read only by terminatePosixProcessTree, which runs only when
there is no lease. Under a lease, teardown is cgroup.kill plus the root identity captured
once at spawn. The walk is unused work on the event loop.

Claude and Codex sessions have no equivalent. They are spawned detached and torn down with one
kill(-pgid) (ClaudeAdapterV2.ts:320, provider-core/src/server/processGroup.ts). Of the
providers in this repo, only provider-grok sets ownDescendantProcessGroups.

Measured impact (T3 v0.1.1, fe27e8e3, headless t3 serve, Ubuntu 26.04, cgroup v2)

Controlled test on one server process. Each Grok session was a task whose only action was
sleep 300. Per session: grok agent --always-approve stdio (46 threads) and
t3 acp-mcp-bridge (11 threads) in their own lease. Main thread measured with
/proc/<pid>/task/<pid>/stat and bpftrace raw_syscalls filtered to the main thread.

Grok sessions main thread CPU main-thread /proc opens/s getdents64/s kernel time in these calls
0 (Claude and Codex sessions live) 6.8% of a core 0 0 —
1, idle 15.6% 2,415 284 5.6% of a core
3, idle 24.6% 6,390 759 12.9% of a core
3, turns finished, sessions still open 21.0% 5,858 395 11.6% of a core
0, after the 30 min idle release 10.2% 0 0 0.03% of a core
  • An idle session runs the walk at the full rate: about 40 passes/s × (one task/<tid>/children
    read per agent thread + stat and readlink exe per process). The cost scales with sessions and
    with the agent's thread count.
  • It lasts beyond the turn. Idle provider sessions are released after DEFAULT_IDLE_TIMEOUT_MS
    (30 min, up to 4 h when pinned; ProviderSessionManager.ts:56-57). The test sessions were
    released 30 min after their last activity, and the /proc traffic stopped with them.
  • Under load the walk runs slower (we saw about 5 passes/s on a busy server), because it shares
    the main thread. Then it shows up as event-loop delay instead of CPU.

This is the measurement requested when #19255 was closed.

Root cause

packages/provider-acp/src/server/AcpSessionRuntime.ts @ fe27e8e3:

  1. Grok enables descendant ownership on Linux:
    provider-grok/src/server/acpSupport.ts#L90-L101.
  2. That creates a cgroup v2 lease and joins the agent to it before exec:
    L1402-L1421.
  3. Without checking for the lease, it then forks the continuous observer for the session's
    lifetime:
    L1493-L1534,
    loop at
    L739-L758
    (25 ms target, inside Effect.sync, so each pass blocks the event loop).
  4. With a lease, graceful teardown
    (L1596-L1609)
    and forced teardown
    (L1624-L1641)
    use only the root identity from the initial capture and terminateLinuxCgroupLease. The ledger
    is consumed only by terminatePosixProcessTree, reached when linuxCgroupLease === undefined.

Proposed fix

Start the continuous observer only when there is no lease. The initial root capture stays, so
signalLinuxCgroupRootTerm still targets the right pid:starttime. Sessions without a lease
(cgroup v1, no delegated cgroup) behave exactly as today.

-    yield* observePosixOwnershipLedgerContinuously({
-      childQueues: posixOwnershipChildQueues,
-      controller: posixController,
-      frontier: posixOwnershipFrontier,
-      ledger: posixOwnershipLedger,
-      root: posixOwnershipRoot,
-      rootPid: Number(child.pid),
-    }).pipe(Effect.forkIn(runtimeScope));
+    // Under a cgroup lease, teardown is cgroup.kill and reads only the root captured above.
+    if (linuxCgroupLease === undefined) {
+      yield* observePosixOwnershipLedgerContinuously({
+        childQueues: posixOwnershipChildQueues,
+        controller: posixController,
+        frontier: posixOwnershipFrontier,
+        ledger: posixOwnershipLedger,
+        root: posixOwnershipRoot,
+        rootPid: Number(child.pid),
+      }).pipe(Effect.forkIn(runtimeScope));
+    }

Test: with a counting fake posixProcessTreeController and a temp-directory lease, assert that
childPidsOf runs once (the initial capture) over an idle window of 10+ intervals, and that closing
the session still empties the lease. #19255 had this test (8 reads instead of 1 on main).

Expected result

Under a lease: 0 /proc opens from idle Grok sessions, the same as Claude and Codex, and about
5–9% of a core of main-thread time back per open Grok session.

Lingua principale
TypeScript
Stelle
24.8k
Fork
6.4k
Merge medio
4h 35m
PR unite (30g)
174

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di pingdotgg/t3code

Tutte le issue di pingdotgg/t3code

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.