Skip to main content

​
Optimize node performance from observed signals

  1. Start from the public readiness and progression signals.
  2. Classify whether the bottleneck is dependency health, local resource pressure, or stalled progression.
  3. Change one tuning dimension at a time.
  4. Re-measure the same signals after each change.
  5. Stop when the node is stable and progressing rather than chasing vague “faster” behavior.

​
1. Use the public signal families as your starting point

Begin with:
  • readiness endpoints
  • runningState and health
  • lastRequest.requestIndex
  • lastTx
  • dependency reachability
  • CPU, memory, disk, and database pressure
Do not tune blindly before classifying which signal family is actually degraded.

​
2. Classify the bottleneck

Use these buckets:
Bottleneck classTypical signal pattern
dependency-boundchain, deployment-service, Postgres, Redis, PCCS, AESM, oracle, or KYC dependency is unstable
progression-boundreadiness is green but request or transaction progression is stalling
resource-boundCPU, memory, disk, or database growth is consistently high
mixedmore than one of the above is failing at once

​
3. Tune one category at a time

Examples:
  • dependency-bound: stabilize the dependency before changing node-local settings
  • progression-bound: inspect whether the node is serving but not advancing, then verify the latest update did not change live coordination behavior
  • resource-bound: relieve the specific pressure first instead of changing multiple services together
Multiple simultaneous tuning changes make verification weaker, not stronger.

​
4. Verify after each tuning change

After any adjustment, re-check:
  1. readiness state,
  2. progression fields,
  3. dependency health,
  4. system-pressure metrics.
If one metric improves while another critical signal regresses, the tuning change is not yet safe.

​
5. Distinguish tuning from recovery

If the node is already unhealthy or drifting from baseline, stop tuning and switch to recovery flow first. Use tuning only when the node is fundamentally serving but not performing as expected.

​
Boundary rule

This guide covers performance-tuning workflow. It does not replace monitoring setup, fixed runtime constants, or private operator runbooks.

​
Next routes

Last modified on April 12, 2026