I am using a 4gb server with 2vcpu And I don’t know why it bugs only with 2 concurrency calls do you know what can be the issue ?

Thanks for reaching out, Michael. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

After doing htop during 2 concurrency calls i got 100% ram use

Thanks — that’s a very helpful datapoint. Since htop shows 100% RAM during two concurrent calls, memory exhaustion is the likely root cause. Here are focused next steps and options to resolve it. What this means • Your server is running out of usable RAM during the two calls. When RAM is exhausted the OS may swap (huge slowdowns) or the OOM killer may terminate processes, which explains the “bugs” you saw. Immediate diagnostics (quick checks) 1. Check for OOM killer entries: ◦ Run

dmesg --ctime | grep -i -E "oom|killed"

or check

/var/log/syslog

or

/var/log/messages

for “Out of memory” or “Killed process” lines. 1. Identify which processes use the most RAM: ◦ In htop sort by memory and note the top 3 processes and their memory usage (RSS). 1. Confirm swap usage: ◦ Run

free -m

and check the Swap line. Heavy swapping confirms RAM pressure. 1. Capture a short log snippet from the LiveKit/agent server around the failure time (any error lines, stack traces, or panic messages). Short-term mitigations you can try now • Restart any nonessential services to free memory while you gather more data. • If you have swap disabled, enable a small swap file (~1–2 GB) temporarily to prevent immediate OOM kills: a.

sudo fallocate -l 2G /swapfile

b.

sudo chmod 600 /swapfile

c.

sudo mkswap /swapfile

d.

sudo swapon /swapfile

e. Add to

/etc/fstab

to make persistent:

/swapfile none swap sw 0 0

Note: Swap reduces performance but prevents abrupt process terminations while you troubleshoot. • If calls include video, switch to audio-only to reduce RAM/CPU per call. • Disable optional on-agent features (noise suppression, local ML models, advanced VAD) if you have them enabled. Medium-term fixes • Upgrade the instance to at least 8 GB RAM and 4 vCPUs if you need on-device processing or expect multiple concurrent calls. Voice AI workloads and model inference commonly need more memory than lightweight audio-only calls. • Use a non-burstable instance to avoid throttling and inconsistent performance. If you’d like, I can give more specific advice — please share: • The top memory-consuming process names and their memory values from htop. • The output of

free -m

. • Any OOM or “killed” lines from dmesg or syslog. • Whether the calls are audio-only or include video, and whether you run local ML/VAD/inference. With those, I’ll recommend the precise configuration change or upgrade and the safest immediate mitigation.

I use vad silerio mois cancellation and multilingual model

Thanks — that’s very helpful. You’re running VAD, noise cancellation, and a multilingual model, and that combination explains why two concurrent calls push your 4 GB / 2 vCPU server to 100% RAM. I’ll walk you through why this happens, immediate mitigations, and recommended next steps. Why this combination uses a lot of RAM • Each active call allocates memory for media pipelines plus any model inference state. VAD and noise cancellation both run per-call processing and can load model artifacts into memory. • Multilingual models are typically larger (more parameters / tokenizer state) and increase per-call memory and possible background memory usage. • With only 4 GB total, two concurrent calls plus system processes easily reach full memory and trigger swapping or OOM kills. Immediate actions you can take right now 1. Reduce per-call processing to test: ◦ Temporarily disable either noise cancellation or the multilingual model and retest with two calls. If disabling one stops the failures, that identifies the biggest memory consumer. 1. Switch to lighter alternatives for testing: ◦ Use a lightweight VAD or disable VAD for the test calls. ◦ Use a smaller language model (if available) or restrict multilingual support to a single language for the test. 1. Add temporary swap to prevent OOM kills: ◦ Create a 1–2 GB swap file to avoid immediate crashes while you test: i.

sudo fallocate -l 2G /swapfile

ii.

sudo chmod 600 /swapfile

iii.

sudo mkswap /swapfile

iv.

sudo swapon /swapfile

v. Add

/swapfile none swap sw 0 0

to

/etc/fstab

◦ Note: swap reduces latency and throughput but prevents abrupt process termination while you troubleshoot. Quick diagnostics to run (paste results here) • In htop, sort by memory and tell me the top 3 processes and their RSS values. •

free -m

output (shows total, used, free, and swap). • Any OOM or “Killed process” lines:

dmesg --ctime | grep -i -E "oom|killed"

. Short- and medium-term fixes • Upgrade memory and CPU: Move to at least 8 GB RAM and 4 vCPUs if you plan to keep VAD + noise cancellation + a multilingual model active. Voice AI and on-device inference commonly require this headroom. • Use dedicated/non-burstable instances to avoid CPU throttling and unpredictable performance. • Offload heavy inference: ◦ Run the multilingual model on a separate inference node or service, not on the same server that handles real-time media. ◦ Use a hosted model or inference cluster if possible. If you want, I can help prioritize which component to disable first for testing. If you paste the htop top processes and the

free -m

output, I’ll give a specific recommendation (e.g., which model or process is consuming the most memory and whether a swap or an instance upgrade is the best next step).

0[|| 1.0%] Tasks: 46, 147 thr, 123 kthr; 2 running 1[|| 2.1%] Load average: 0.44 0.36 0.15 2[|| 2.1%] Uptime: 000245 3[| 0.5%] Mem[|||||||||||||||||||||||||||||||||||||||||||||||||| 2.83G/7.56G] Swp[ 0K/0K] [Main] [I/O] PID USER PRI NI VIRT RES SHR S CPU%▽MEM% TIME+ Command 1848 root 20 0 8708 5228 3824 R 3.6 0.1 0:00.76 htop 1257 root 20 0 2216M 380M 67920 S 0.5 4.9 0:06.59 python agent.py start --log-level=ERROR 1360 root 20 0 1077M 280M 20824 S 0.5 3.6 0:01.27 /app/agents/.venv/bin/python -c from multiprocessing.forkserver import main; main(16, 18, ['livekit.plugins.silero', 'livekit. 1390 root 20 0 2216M 380M 67920 S 0.5 4.9 0:00.12 python agent.py start --log-level=ERROR 1398 root 20 0 15692 11796 9136 S 0.5 0.1 0:00.20 sshd: root@notty 1553 root 20 0 11.2G 109M 52884 S 0.5 1.4 0:01.38 /root/.vscode-server/cli/servers/Stable-c9d77990917f3102ada88be140d28b038d1dd7c7/server/node /root/.vscode-server/cli/servers/ 1584 root 20 0 62.2G 498M 64628 S 0.5 6.4 0:00.43 /root/.vscode-server/cli/servers/Stable-c9d77990917f3102ada88be140d28b038d1dd7c7/server/node --dns-result-order=ipv4first /roo 1607 root 20 0 1128M 75956 48556 S 0.5 1.0 0:00.53 /root/.vscode-server/cli/servers/Stable-c9d77990917f3102ada88be140d28b038d1dd7c7/server/node /root/.vscode-server/cli/servers/ 1 root 20 0 22100 13304 9544 S 0.0 0.2 0:02.12 /sbin/init 350 root 19 -1 34056 12872 11724 S 0.0 0.2 0:00.25 /usr/lib/systemd/systemd-journald 402 root RT 0 282M 27452 8760 S 0.0 0.3 0:00.02 /sbin/multipathd -d -s 411 root 20 0 282M 27452 8760 S 0.0 0.3 0:00.00 /sbin/multipathd -d -s 413 root RT 0 282M 27452 8760 S 0.0 0.3 0:00.00 /sbin/multipathd -d -s 414 root RT 0 282M 27452 8760 S 0.0 0.3 0:00.00 /sbin/multipathd -d -s 415 root RT 0 282M 27452 8760 S 0.0 0.3 0:00.00 /sbin/multipathd -d -s 416 root RT 0 282M 27452 8760 S 0.0 0.3 0:00.01 /sbin/multipathd -d -s F1Help F2Setup F3SearchF4FilterF5Tree F6SortByF7Nice -F8Nice +F9Kill F10Quit

Thanks — this is very helpful. I can see from your htop output that RAM is indeed the constraint: total memory is ~7.56 GB with 2.83G used (your earlier 4 GB note seems updated to ~8GB now), and the largest memory consumers are several Python processes (agent.py and related worker processes) plus multiple VS Code server node processes. You also confirmed you’re running VAD (Silero), noise cancellation, and a multilingual model — those together explain high per-call memory. What I recommend next (ordered: fast checks, short-term mitigations, and longer-term fixes) Fast checks (paste results here if anything looks odd) • Confirm which Python process is the real agent instance: in htop note the full command for the PIDs ~1257/1390/1360/1553/1584/1607 so we can identify duplicated or leftover processes. • Run

free -m

and paste the output so I can confirm available vs. used memory and swap state. • Check for OOM messages:

dmesg --ctime | grep -i -E "oom|killed"

. Short-term mitigations you can try now 1. Reduce running dev tools: stop VS Code server (those node processes show large VIRT/RSS — they’re using ~600+ MB each). This will free a few hundred MBs immediately. ◦ Example: stop the remote VS Code server or disconnect IDE sessions while load-testing. 1. Temporarily disable one heavy component: ◦ Disable the multilingual model for a test run (keep VAD and noise cancel on) or disable noise cancellation and retest. This identifies the biggest memory consumer quickly. 1. Add a temporary 1–2 GB swap file to avoid OOM kills while you test: ◦

sudo fallocate -l 2G /swapfile

◦

sudo chmod 600 /swapfile

◦

sudo mkswap /swapfile

◦

sudo swapon /swapfile

◦ Add

/swapfile none swap sw 0 0

to

/etc/fstab

if you want persistence. Immediate diagnostic goal: get memory headroom so two calls can run without hitting OOM while we identify the largest consumer. What to look for after changes • If disabling the multilingual model fixes two concurrent calls, the model is the main memory pressure and should be offloaded or run on a larger host. • If disabling noise cancellation fixes it, consider using a lighter cancellation implementation or offloading this processing. • If stopping VS Code server processes fixes it, keep development services off production nodes. Medium-term fixes (recommended) • Move heavy inference/model workload off the real-time media host. Run the multilingual model on a separate inference node (or managed hosting) and call it from your agents. This keeps media agents lightweight. • Upgrade to a larger instance: target at least 8 GB RAM and 4 vCPUs when running VAD + noise cancellation + a multilingual model on the same host. • Use a non-burstable/dedicated CPU instance to avoid CPU credit throttling and unpredictable latencies. If you want, I can give a prioritized exact next step: • Option A (quickest test): Stop VS Code server processes and add 2GB swap, then retry two calls. Tell me whether it succeeds. • Option B (to identify culprit): Disable the multilingual model and rerun two calls. Tell me whether it succeeds. Which option would you like to try first? If you run one and paste the

free -m

output plus the top 5 processes by RES after the test, I’ll give the next precise recommendation (exact upgrade size or offloading strategy).

root@ubuntu-4gb-hel1-4:~/VoiceAI_livekit# free -m total used free shared buff/cache available Mem: 7745 3161 3585 4 1267 4584 Swap: 0 0 0 root@ubuntu-4gb-hel1-4:~/VoiceAI_livekit#

Thanks — this is great information. I can see from

free -m

that you have ~7.7 GB total, 3.16 GB used, ~3.6 GB free, and no swap. That matches your htop output: several Python agent processes plus VS Code server processes are consuming memory. Since you previously reported the problem happened when two concurrent calls run with VAD (Silero), noise cancellation, and a multilingual model, this combination is the likely cause of memory pressure once both calls are active. What I recommend next (concise, actionable) 1) Run the two-call test while monitoring peak memory • Start the two concurrent calls and during the failure run: ◦

free -m

(paste output) ◦ In htop sort by RES and note the top 5 processes and their RES values This confirms which process(es) spike when the second call starts. 2) Immediate mitigations to free headroom (pick one to try now) • Stop the VS Code server (those node processes show large RSS) or other dev services on that machine to free several hundred MB each. • Add temporary swap (prevents OOM kills while you test): a.

sudo fallocate -l 2G /swapfile

b.

sudo chmod 600 /swapfile

c.

sudo mkswap /swapfile

d.

sudo swapon /swapfile

e. Optional: add

/swapfile none swap sw 0 0

to

/etc/fstab

Note: swap reduces performance but avoids abrupt process termination. 3) Identify the biggest memory consumer (quick A/B tests) • Option A (quick): Disable the multilingual model and run two calls. If memory issue disappears, the model is the main consumer. • Option B (alternate): Disable noise cancellation and test. If this fixes it, offload or replace noise cancel for now. • Option C (if available): Use a smaller model or single-language mode for testing. 4) Medium-term recommendations • For production with VAD + noise cancellation + multilingual inference on the same host, use at least 8 GB RAM and 4 vCPUs. Running heavy model inference on the media host is not recommended long-term. • Offload the multilingual model to a separate inference node or managed model service. Keep the media/agent host focused on real-time media pipelines. • Use non-burstable/dedicated instances to avoid throttling. What I need from you next (choose one) • After you run step 1 (two-call test), paste the

free -m

output and the top 5 RES processes from htop during the failure — I’ll pinpoint which process to stop or whether the model is the culprit. • Or tell me which immediate mitigation you tried (stopped VS Code server or added swap) and whether the two calls now succeed. If you want, try stopping VS Code server + enabling 2G swap and rerun the test, then paste the new

free -m

and top processes — I’ll give the exact next step (disable model vs upgrade vs offload).