Web Meeting always in Mesh Mode and Users CPU/RAM utilisation is always 80%

Hi All,

New to Jitsi here. I am running Jitsi for 50 users on a decent server with 8 vCPU and 32 GB RAM.
when I do a netstat on any of the machines, I see direct session to other participants and CPU & Memory utilisation is always like 80%. On the same time no load on server at all.

Also everything starts to fall apart as soon as 7-8th guy joins the meeting, all end points becomes virtually unusable and all bandwidth is chugged by Jitsi.

Please help.

Regards,

What is your server available bandwidth? Are these set: https://github.com/jitsi/jitsi-videobridge/blob/master/config/20-jvb-udp-buffers.conf?

Thanks for the quick reply but in which file do I need to add these lines ?

These are sysctl options which are set by default when installing jvb.

do you use Jitsi the application or Jitsi-meet the web server system ?

Its Jitsi-Meet

I guess this could be the issue -

java.lang.Exception: Address discovery through STUN failed
at org.jitsi.videobridge.health.Health.performCheck(Health.java:195)
at org.jitsi.health.AbstractHealthCheckService.run(AbstractHealthCheckService.kt:144)
at org.jitsi.utils.concurrent.RecurringRunnableExecutor.run(RecurringRunnableExecutor.java:216)
at org.jitsi.utils.concurrent.RecurringRunnableExecutor.runInThread(RecurringRunnableExecutor.java:292)
at org.jitsi.utils.concurrent.RecurringRunnableExecutor.access$000(RecurringRunnableExecutor.java:36)
at org.jitsi.utils.concurrent.RecurringRunnableExecutor$1.run(RecurringRunnableExecutor.java:328)
2020-06-26 23:18:30.787 SEVERE: [20] AbstractHealthCheckService.run#174: Health check failed in PT0S:
java.lang.Exception: Address discovery through STUN failed
at org.jitsi.videobridge.health.Health.performCheck(Health.java:195)
at org.jitsi.health.AbstractHealthCheckService.run(AbstractHealthCheckService.kt:144)
at org.jitsi.utils.concurrent.RecurringRunnableExecutor.run(RecurringRunnableExecutor.java:216)
at org.jitsi.utils.concurrent.RecurringRunnableExecutor.runInThread(RecurringRunnableExecutor.java:292)
at org.jitsi.utils.concurrent.RecurringRunnableExecutor.access$000(RecurringRunnableExecutor.java:36)
at org.jitsi.utils.concurrent.RecurringRunnableExecutor$1.run(RecurringRunnableExecutor.java:328)
2020-06-26 23:18:40.787 SEVERE: [20] AbstractHealthCheckService.run#174: Health check failed in PT0S:
java.lang.Exception: Address discovery through STUN failed
at org.jitsi.videobridge.health.Health.performCheck(Health.java:195)
at org.jitsi.health.AbstractHealthCheckService.run(AbstractHealthCheckService.kt:144)
at org.jitsi.utils.concurrent.RecurringRunnableExecutor.run(RecurringRunnableExecutor.java:216)
at org.jitsi.utils.concurrent.RecurringRunnableExecutor.runInThread(RecurringRunnableExecutor.java:292)
at org.jitsi.utils.concurrent.RecurringRunnableExecutor.access$000(RecurringRunnableExecutor.java:36)
at org.jitsi.utils.concurrent.RecurringRunnableExecutor$1.run(RecurringRunnableExecutor.java:328)

My server does not have internet access and I just found this config -

// Use XEP-0215 to fetch STUN and TURN servers.
useStunTurn: true,

    // The STUN servers that will be used in the peer to peer connections
    stunServers: [

        // { urls: 'stun:XXX.XXXXXXXXXXX.com:4446' },
        { urls: 'stun:meet-jit-si-turnrelay.jitsi.net:443' }
    ],

I guess this is causing the issue. Can I change it to my local server as cotrun service is up & running.

My server is 8 Core, 32 GB RAM, 480GB SSD, 10G Link and running on ubuntu 18.04. All my users are connected via MPLS and minimum bandwidth to any site is 10 MBPS.

I have changed the buffers settings and all other settings mentioned in forum like

SET_FILMSTRIP_ENABLED: false, (this is not working though)
DISABLE_FOCUS_INDICATOR: true,
DISABLE_DOMINANT_SPEAKER_INDICATOR: true,
DISABLE_JOIN_LEAVE_NOTIFICATIONS: true,

And have disable almost all automation and H264 by default. Also disable hardware acceleration in chrome

All end users are i5 7th Gen or higher and still doing above 70% CPU and sometimes spikes to 100%

Any suggestion what else can be done to contain it.