Bug in JVB ?!

Hello friends

My JVB file absorbs CPU resources but never releases it.

Every class that ends and all users leave the class, the JVB does not free up resources, and the next class adds the CPU usage to the previous level so that the CPU is 100% busy and I have to reset the server.

my java version:

where is the problem from ?

Share your jvb config, please.

1 Like

Thank you for answering.


What about sip-communicator.properties does it exist and is it empty?

1 Like

it’s exist and empty.


What prosody version do you use?

1 Like

What does the following command output?

cat /sys/devices/system/clocksource/clocksource0/current_clocksource
1 Like

few questions:

  • does your system have enough resources: 8 Gb Ram minimum (if you use the default -Xmx5120)
  • you say: ‘when the class’: a school has usually more than one class, often there are many students/children and it’s difficult to control them all, are you sure that your system is secured enough that children/students can’t take control of rooms for well, mischief as children/students are prone to do ?
1 Like




This is fine.

1 Like

1- yes
my server:
Intel Xeon 3
cpu count : 4 core
memory : 12 G DDR4

2- Yes you are right
Unfortunately, I have these problems.
I’m not a professional, I started this system for students because of Covid-19, but I still haven’t been able to do well.

Do you have any idea to solve my problem?

Check JVB logs, check the REST debug endpoints to see if maybe you have more conferences/participants than you think you do, a packet capture may give some clues, you could use a profiler to find out what it is doing with all that CPU time, …

1 Like

To get jicofo stats

curl -s
1 Like

{“xmpp_service”:{“total_recv”:25951,“total_sent”:8771},“largest_conference”:0,“c onference_sizes”:[0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0],“total_conference s_created”:16,“threads”:221,“xmpp”:{“total_recv”:25951,“total_sent”:8771},“jingl e”:{“received”:{“session-accept”:36,“transport-info”:36,“source-remove”:19,“sour ce-add”:37,“session-terminate”:1},“sent”:{“source-remove”:84,“source-add”:213,“s ession-terminate”:4,“session-initiate”:36}},“bridge_failures”:{“participants_mov ed”:0,“bridges_removed”:0},“avg_allocate_channels_req_time_nanos”:0.0,“total_par ticipants”:43,“participant_notifications”:{“ice_failed”:0,“request_restart”:1}," queues":{“JitsiMeetConference-queueExecutor”:{“added_packets”:2469,“removed_pack ets”:2469,“dropped_packets”:0,“duration_s”:81065.970997,“average_remove_rate_pps “:0.03045667583617015,“queue_size_at_remove”:{“average_queue_size_at_remove”:1.1 929468990676935,“max_queue_size_at_remove”:8,“total_value”:2943,“total_count”:24 67,“buckets”:{”<= 0”:804,"<= 1":749,"<= 4":851,"<= 16":63,"<= 64":0,"<= 256":0," <= 1024":0,"<= 4096":0,"<= 16384":0,"> 16384":0,“p99<=”:16,“p999<=”:16}}}},“jiga si”:{},“bridge_selector”:{“total_least_loaded_in_region”:0,“total_split_due_to_l oad”:0,“total_not_loaded_in_region_in_conference”:0,“in_shutdown_bridge_count”:0 ,“total_least_loaded_in_region_in_conference”:0,“total_not_loaded_in_region”:0," total_split_due_to_region":0,“bridge_count”:1,“operational_bridge_count”:1,“tota l_least_loaded_in_conference”:0,“total_least_loaded”:8},“jibri”:{“total_sip_call _failures”:0,“live_streaming_pending”:0,“recording_pending”:0,“live_streaming_ac tive”:0,“total_recording_failures”:0,“sip_call_pending”:0,“sip_call_active”:0,“t otal_live_streaming_failures”:0,“recording_active”:0},“conferences”:0,"participa

Have you tried removing the -Xmx5120 and leaving the default …

1 Like

At first it was in the state of 3 mg and there was a problem.

Can you share all your current jvb configs, please.

When you think there are no conferences since at least 5 mins, and you see the CPU usage do:
curl -s > stats.json

And upload the file here

a few remarks

  • you asked is there a bug in JVB ? no one answered that and the true answer is that (as in any complex software) there are many bugs in JVB, but this particular one (a big memory leak) should be found out quite fast in big Jitsi installations. However you never said which Jitsi-meet version you are using, and it may be that you use a old version where such a problem has been found, fixed, and forgotten. If you are up-to-date the bug probability is much less but a bug could be triggered if doing very particular customizations.

  • @emrah’s useful reply could have been completed by adding a | jq at end that would have made the json output more readable (jq can be installed with apt install jq on debian systems)

  • if mischief is possible, you could try to use the scripts attached to this post (inspiration coming from this post that you should read before using the scripts if enabling admin_telnet prosody module’ is not clear enough, errors in the scripts are of course coming from me exclusively, it’s up to you to rename the files, chmod +x and set in a search path)

lstrooms_prosody.txt (269 Bytes)

lstocc.txt (651 Bytes)