Thanks — I hear you’re seeing high CPU from

Nodebox

and

c3_pool

while recording calls. I can help troubleshoot, but I need a few details to pinpoint causes and suggest fixes. Please confirm / share: • Are

Nodebox

and

c3_pool

part of your LiveKit deployment or separate apps/services? If separate, what do they do? • Which LiveKit components are running for recording: the built-in Egress service, Universal Egress, or a custom recorder? • Server specs (CPU cores, RAM) and OS. • How many concurrent recordings/participants when CPU spikes? • Any relevant logs or top/htop snapshots showing CPU use by process (output of

top -b -n1 | head -n 20

or

ps aux --sort=-%cpu | head

). • Egress config (single file per call, per-room recording, transcoding enabled?). • Are you running on a single machine for SFU + Egress + DB, or using separate hosts/containers? • Does the high CPU persist after recordings stop, or only during active recording? Quick guidance while you gather info: • Transcoding/encoding in Egress is CPU-heavy; use lower resolution/bitrate or offload to separate host to reduce load. • Run SFU and Egress on different machines/containers so recording work doesn’t compete with real-time forwarding. • Scale Egress horizontally (multiple egress instances) if you record many concurrent sessions. • If you’re using Universal Egress/FFmpeg, ensure you’re not using expensive codecs or unnecessary simultaneous outputs. Send the answers and any process logs/output and I’ll recommend specific config changes or steps to reduce CPU. Sources: Going beyond a single-core | Universal Egress | Recording and export | LiveKit docs | Self-hosting the Egress Service | LiveKit docs