Environment:
Agent Zero v2.11, Docker container, Ubuntu 24.04
VPS: 2 vCPU / 4GB RAM (KVM hypervisor)
Supervisord managing run_ui, run_cron, run_tunnel_api
Observation:
After updating to v2.11, run_ui consumes ~45% CPU on a 2-vCPU server at idle (no active chat sessions). Prior to the v2.11 update, idle CPU was ~4%. The increase appears immediately after the update and persists indefinitely.
Diagnostics performed:
PyTorch eliminated as cause:
top -H showed hot thread named pt_main_thread initially
Traced to sentence_transformers importing torch at module level in models.py (line 46, from sentence_transformers import SentenceTransformer)
Made import lazy (deferred to inside _get_local_embedding_model()) — freed ~750MB RAM
Also commented out top-level kokoro_tts and whisper_stt imports in preload.py
After fix: pt_main_thread disappeared from run_ui entirely
Residual 45% CPU — pure Python asyncio:
Hot thread renamed to python (generic name, not PyTorch)
wchan=ep_poll — thread sleeping in epoll_wait(), waking on network events
Context switches: ~440/2s baseline, spiking to ~1,988/2s every ~60 seconds (likely job_loop firing)
docker logs --since 5m returns quickly with no error loops
No active chat sessions during measurement
ss -tn and further asyncio profiling not completed — py-spy not available in this environment
What has NOT been investigated (requires py-spy or built-in profiling):
Which specific coroutine/callback is responsible for ~1,250 network wakeups/second at idle
Whether ACP session bridge, fasta2a server, or new WebSocket handling introduced in v2.11 is polling or keeping connections alive unnecessarily
Whether the job_loop task schedule changed between v2.10 and v2.11
Request:
Could the team advise what changed in v2.11 regarding background task scheduling or async connection management? A built-in profiling endpoint or py-spy guide for Docker deployments would help isolate this further. The 45% idle CPU on a shared VPS risks hypervisor throttling and makes the platform unsuitable for always-on VPS deployments without significant over-provisioning.
Environment:
Agent Zero v2.11, Docker container, Ubuntu 24.04
VPS: 2 vCPU / 4GB RAM (KVM hypervisor)
Supervisord managing run_ui, run_cron, run_tunnel_api
Observation:
After updating to v2.11, run_ui consumes ~45% CPU on a 2-vCPU server at idle (no active chat sessions). Prior to the v2.11 update, idle CPU was ~4%. The increase appears immediately after the update and persists indefinitely.
Diagnostics performed:
PyTorch eliminated as cause:
top -H showed hot thread named pt_main_thread initially
Traced to sentence_transformers importing torch at module level in models.py (line 46, from sentence_transformers import SentenceTransformer)
Made import lazy (deferred to inside _get_local_embedding_model()) — freed ~750MB RAM
Also commented out top-level kokoro_tts and whisper_stt imports in preload.py
After fix: pt_main_thread disappeared from run_ui entirely
Residual 45% CPU — pure Python asyncio:
Hot thread renamed to python (generic name, not PyTorch)
wchan=ep_poll — thread sleeping in epoll_wait(), waking on network events
Context switches: ~440/2s baseline, spiking to ~1,988/2s every ~60 seconds (likely job_loop firing)
docker logs --since 5m returns quickly with no error loops
No active chat sessions during measurement
ss -tn and further asyncio profiling not completed — py-spy not available in this environment
What has NOT been investigated (requires py-spy or built-in profiling):
Which specific coroutine/callback is responsible for ~1,250 network wakeups/second at idle
Whether ACP session bridge, fasta2a server, or new WebSocket handling introduced in v2.11 is polling or keeping connections alive unnecessarily
Whether the job_loop task schedule changed between v2.10 and v2.11
Request:
Could the team advise what changed in v2.11 regarding background task scheduling or async connection management? A built-in profiling endpoint or py-spy guide for Docker deployments would help isolate this further. The 45% idle CPU on a shared VPS risks hypervisor throttling and makes the platform unsuitable for always-on VPS deployments without significant over-provisioning.