Troubleshooting Performance & Bottlenecks
RUSEON Core is engineered for high-concurrency video streaming with sub-millisecond playlist delivery and zero-copy frame routing. If you observe elevated CPU usage, memory growth, or frame drops, use this guide to identify and resolve the root bottleneck.
1. High CPU Utilization
Under normal operation, RUSEON Core consumes negligible CPU because it transmuxes rather than transcodes.
Remediation Steps:
- Disable Debug Logging: Running in debug mode (
server.debug: true) incurs additional logging overhead. Ensureserver.debug: falsein production. - Inspect pprof CPU Profile: If
server.pprof_port: 6060is enabled:bashgo tool pprof -top http://localhost:6060/debug/pprof/profile?seconds=30 - Inspect Real-Time Memory Visualizer (Statsviz): Navigate to
http://localhost:8080/debug/statsviz/in your browser for live Goroutine, Heap, and GC allocation graphs.
2. Memory Growth & Garbage Collection Tuning
If RAM usage climbs unexpectedly:
- Configure GC Tuning in
config.yaml: RUSEON Core provides built-in Go runtime memory limits:yamlserver: gc_percent: 50 # Default GOGC target gc_memory_limit_mb: 2048 # GOMEMLIMIT soft ceiling - Page Cache vs Process Memory: Distinguish between RUSEON's RSS memory and the Linux kernel Page Cache:bashRUSEON automatically invokes
# Check actual process RSS memory ps -aux | grep ruseon # Check Linux Page Cache vs Free RAM free -hPOSIX_FADV_DONTNEEDto prevent Page Cache thrashing.
3. Buffer Drops & Slow Consumer Saturation
If ruseon_ringbuffer_drops_total is increasing in Prometheus:
- Root Cause: An outbound subscriber channel (a slow WebRTC client or high-latency disk write) is not draining frames fast enough.
- Protection: The RingBuffer drops non-keyframe P-frames for that specific subscriber and sets the
NeedsIFrameflag to preserve global server stability. - Remediation: Check network bandwidth between RUSEON and client players, or optimize disk write throughput.