Repository navigation
fix(server): sqlite commits no longer fsync on the event loop - #60
Merged
Merged
Conversation
Thread transfer impact✅ Thread transfer remains within every enforced ceiling.
Baseline: Scenario and decoded snapshot size10 historical turns, 5 command tools per turn, 878.9 KiB retained MCP result per historical turn, and a 1.05 MiB retained result in the measured turn.
Updated in place by a trusted workflow. PR artifacts are strictly validated and never executed. |
This was referenced Oct 11, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
On lax6e the server's event loop stalls for 2–15s several times an hour, and the long ones drop every connected client. Today's 15.6s stall at 17:17 UTC disconnected the desktop.
The stalls were blocked waiting, not computing. The 30s sample around the 15.6s stall shows the loop busy (utilization 0.86) on only about 5s of CPU. I sampled the main thread every 200ms from
/procand caught the next stall (3178 ms logged at 17:49:58). The thread spent about 3.2s in stateDinside syscall 74 (fsync), waiting onjbd2_log_wait_commit. That is SQLite's per-commit fsync, waiting on the ext4 journal of a busy, nearly full disk. CPU priority was not the issue: the service already hasCPUWeight=1000, and its cgroup's CPU pressure is about 0.1%.node:sqliteis synchronous and runs on the event loop. We never setsynchronous, so SQLite used its defaultFULL, which fsyncs the WAL on every commit.Fix
PRAGMA synchronous = NORMALinlayerSetup. This is SQLite's recommended setting for WAL:There is a single read-write connection, and the other
DatabaseSyncopeners are read-only, so this one pragma covers every writer.Verification
vp test run src/persistence: 60/60 pass.strace -c, 200 WAL commits made 209 fsyncs with FULL and 8 with NORMAL.🤖 Generated with Claude Code (Opus 5.5)