fix(cuprate): enable fast_sync and raise DB cache — sustained 45% CPU #153

Merged
chaum merged 2 commits from cuprate-cpu-fix into main 2026-09-07 07:24:26 +00:00
Collaborator

Summary

  • The apps/cuprate manifest baked in the exact broken config found on an affected fleet node: fast_sync unset (defaults false, forcing full ring-signature/RandomX verification on every incoming block instead of trusting checkpointed history) and target_max_memory capped at ~2.8GiB, which starved cuprated's DB cache into constant eviction/flush.
  • A reference node with fast_sync = true and an 8GiB cache ran at 2.8% CPU vs. a sustained 45% on the affected node, at the same chain height and block rate, with I/O dropping from ~595GB/24h to a normal trickle after the fix.
  • Sets fast_sync = true and target_max_memory = 8589934592 (8GiB) in the shipped Cuprated.toml, and raises resources.memory_limit from 4Gi to 10Gi so the container keeps headroom above the larger cache.

Test plan

  • python3 -c "import yaml; yaml.safe_load(open('apps/cuprate/manifest.yml'))" — manifest parses (done locally)
  • Deploy/redeploy the cuprate app on a fleet node and confirm podman stats settles to low single-digit CPU and normal block I/O after resync
  • Confirm Cuprated.toml on disk reflects fast_sync = true and the raised target_max_memory

🤖 Generated with Claude Code

https://claude.ai/code/session_01RR7jRaicvqsJaqQQ92jpPQ

## Summary - The `apps/cuprate` manifest baked in the exact broken config found on an affected fleet node: `fast_sync` unset (defaults false, forcing full ring-signature/RandomX verification on every incoming block instead of trusting checkpointed history) and `target_max_memory` capped at ~2.8GiB, which starved cuprated's DB cache into constant eviction/flush. - A reference node with `fast_sync = true` and an 8GiB cache ran at 2.8% CPU vs. a sustained 45% on the affected node, at the same chain height and block rate, with I/O dropping from ~595GB/24h to a normal trickle after the fix. - Sets `fast_sync = true` and `target_max_memory = 8589934592` (8GiB) in the shipped `Cuprated.toml`, and raises `resources.memory_limit` from 4Gi to 10Gi so the container keeps headroom above the larger cache. ## Test plan - [ ] `python3 -c "import yaml; yaml.safe_load(open('apps/cuprate/manifest.yml'))"` — manifest parses (done locally) - [ ] Deploy/redeploy the cuprate app on a fleet node and confirm `podman stats` settles to low single-digit CPU and normal block I/O after resync - [ ] Confirm `Cuprated.toml` on disk reflects `fast_sync = true` and the raised `target_max_memory` 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01RR7jRaicvqsJaqQQ92jpPQ
ssmithx added 1 commit 2026-09-03 08:58:09 +00:00
The default manifest baked in the exact broken config found on an
affected fleet node: no fast_sync (defaults false, forcing full ring-sig/
RandomX verification on every block) and target_max_memory capped at
~2.8GiB, which starved cuprated's DB cache into constant eviction/flush
(595GB/24h of block I/O on a node just appending ~2MB blocks every 2
minutes). A reference node with fast_sync = true and an 8GiB cache ran
at 2.8% CPU at the same chain height and block rate.

Set fast_sync = true and target_max_memory = 8GiB to match the healthy
reference config, and raise resources.memory_limit from 4Gi to 10Gi so
the container still has headroom above the larger cache.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RR7jRaicvqsJaqQQ92jpPQ
ssmithx added 1 commit 2026-09-03 14:52:44 +00:00
The restricted-RPC port (18090) was `auth: none`, which the app gate
treats as fully exempt — no onion, no takeover, LAN/Tailscale IP only.
Flip it to `auth: open`: the gate still binds the external addresses
and fronts a Tor onion for the port, just without a dashboard login
challenge, since Monero wallet clients (Feather, monero-wallet-rpc,
GUI) speak plain HTTP JSON-RPC and can't hold a session cookie.

P2P (18183) stays `none` — no reason to Tor-front raw gossip.

Regenerated releases/app-catalog.json (unsigned) to embed the updated
manifest; needs scripts/sign-catalog.sh before it takes effect on any
node, since origin (catalog) wins over disk for catalog-covered apps.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NZnsiMtyJxiJBuvv7yLPUF
chaum merged commit be06e1a502 into main 2026-09-07 07:24:26 +00:00
Sign in to join this conversation.