docker-jitsi-meet icon indicating copy to clipboard operation
docker-jitsi-meet copied to clipboard

jvb detects wrong number of CPU:s

Open JosefWN opened this issue 2 years ago • 9 comments

Description:

JVB is running on a single thread even though many cores are available.

Steps to reproduce:

Run the official jitsi-meet Docker images on a multi-core machine.

Expected behavior:

Jitsi should be able to use more than one CPU. From within the JVB container:

$ lscpu
CPU(s):                          96
Thread(s) per core:              2
Core(s) per socket:              24
Socket(s):                       2

Actual behavior:

INFO: TaskPools detected 1 processors, creating the CPU pool with that many threads

Server information:

  • Jitsi Meet version: 6726
  • Operating System: Linux x86-64

JosefWN avatar Jan 11 '22 18:01 JosefWN

Hello

did you consider to post this issue under the jitsi-videobridge project instead of this one ? Maybe this issue is relevant.

gpatel-fr avatar Jan 11 '22 18:01 gpatel-fr

Please, when you have questions or problems use the community forum before opening new issues, thank you.

damencho avatar Jan 11 '22 18:01 damencho

What is the java version you use?

damencho avatar Jan 11 '22 18:01 damencho

Whoops, sorry, thanks for moving it!

I'm using this particular container: https://hub.docker.com/layers/jitsi/jvb/stable-6726/images/sha256-e8edd2fdf42caf89434c906c566e1049b39271e6d4be363cc682c36c12a5b31c?context=explore

From within the container itself:

# java -version
openjdk version "11.0.13" 2021-10-19
OpenJDK Runtime Environment (build 11.0.13+8-post-Debian-1deb11u1)
OpenJDK 64-Bit Server VM (build 11.0.13+8-post-Debian-1deb11u1, mixed mode, sharing)

JosefWN avatar Jan 11 '22 18:01 JosefWN

Where did you execute the lscpu? On the host or in the docker image of the bridge? I suspect this is how docker works ... I'm not familiar with it, but I guess it uses just one CPU for that image of the jvb and you need to adjust that.

damencho avatar Jan 11 '22 18:01 damencho

I executed lscpu inside the docker container of the bridge, and Kubernetes has no constraints on the resources, so the whole machines' resources should be available to all containers.

I can verify this by putting some load on the specific JVB container:

# stress --cpu 4

Then measuring the load on the container (4006m is 4.006 cores):

# kubectl top po 
NAME                      CPU(cores)   MEMORY(bytes)     
jvb-56f8fcb695-5bjr4      4006m        330Mi 
...

Could go higher too but I didn't feel like maxing out the entire machine.

JosefWN avatar Jan 11 '22 19:01 JosefWN

https://stackoverflow.com/questions/57003259/runtime-getruntime-availableprocessors-is-always-returning-1-on-container-op?rq=1

damencho avatar Jan 11 '22 19:01 damencho

You can use /etc/jitsi/videobridge/config to pass params. Or maybe open a PR in the docker repo. I will once again move this issue, as it has nothing to do with jvb, but it is docker.

damencho avatar Jan 11 '22 19:01 damencho

I just tried with a small example in Java and I can confirm this is indeed the issue. One step closer... thanks!

JosefWN avatar Jan 11 '22 19:01 JosefWN

Running k8s v1.25 and Jitsi stable-6865 this is no longer an issue. Closing.

JosefWN avatar Nov 06 '22 16:11 JosefWN