Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở Phù hợp với người mới
  • Có gì không ổn?
#23,393 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
2/5
Thời gian dự kiến
1-3 giờ
Mức phù hợp với người mới
78/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
linux, typescript
Lĩnh vực
backend, performance

Hướng nghiên cứu

Bắt đầu tại packages/provider-acp/src/server/AcpSessionRuntime.ts, ở phần thiết lập cgroup lease và trình theo dõi ownership liên tục. Kiểm tra các nhánh teardown để xác nhận ownership ledger chỉ được dùng khi không có lease, sau đó thêm hoặc cập nhật bài kiểm thử dùng counting-controller được mô tả trong issue. Hoàn tất khi trình theo dõi chỉ ghi nhận root một lần trong lease, việc polling khi idle dừng lại và đóng session làm lease trống.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
TypeScript
Star
24.8k
Fork
6.4k
Merge trung bình
1 giờ 22 phút
Pull request đã merge (30 ngày)
18

Chuẩn bị môi trường

Mở trong Codespaces

Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của pingdotgg/t3code

Tất cả issue của pingdotgg/t3code

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.