This message was deleted.
# helpdesk
s
This message was deleted.
d
cpuload is probably the better metric to use. sysload is slower reacting. what are you setting the threshold to? how quickly are these rooms being spun up?
p
Hi, I've this:
node_selector: kind: cpuload sort_by: cpuload cpu_load_limit: 0.5
I've some initial pods in eks and some placeholders to speed up new pods when necessary. When I start stress testing around 30% avg cpu, the hpa launches more livekit pods. I was expecting to see the initial pods(nodes) going up only to 50-60% due to nodeselector but they go all way up to 100% cpu!
d
how many users are joining per second? and how is your HPA set up? If the pods are spinning up slower than demand, you'd need to spin up more capacity ahead of the time. there are probably more tuning necessary in the node selector stack too. Can you log the CPU load over time (i.e. one log entry every 2 seconds) ? It'd be good to see how they are responding to the traffic increases
p
Hi, please take a look in the pic attached. It shows the initial and subsequent created nodes. The initial nodes keep receiving new rooms and respective participants all the way even when the cpu is above the defined limit.
d
this is showing me number of rooms per node, without information about • CPU load on these nodes • amount of traffic each room is doing If rooms are allocated, and then they keep getting larger, that would also push the CPU utilization above the limit previously set.
p
Hi, The number is room allocated per node at that minute in the initial ~10m(Numbers are not cumulative). After the room is created it handles 5 subs/pubs for 25m, then all participants disconnect. I'l work on getting the cpu load and bandwith data integrated in logs for better insight.
d
can you share your config as well?