Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto Apto para principiantes
  • ¿Algo no está bien?
#23,393 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
78/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
linux, typescript
Área
backend, performance

Línea de trabajo

Empieza en packages/provider-acp/src/server/AcpSessionRuntime.ts, en la configuración del lease de cgroup y del observador continuo de ownership. Revisa las ramas de teardown para confirmar que el ledger de ownership solo se usa sin un lease y, después, añade o actualiza la prueba con el controlador contador descrita en el issue. El trabajo estará terminado cuando el observador capture la root una vez bajo un lease, se detenga el sondeo en reposo y el cierre de la sesión vacíe el lease.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
TypeScript
Estrellas
24.8k
Forks
6.4k
Merge medio
1 h 22 min
PR fusionados (30 d)
18

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de pingdotgg/t3code

Todos los issues de pingdotgg/t3code

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.