Jibri eating all memory

timowevel1 commented

2021-06-23 08:22:32 +00:00

(Migrated from github.com)

I experienced something really weird. I got four machines, all machines got the same specs (4 Cores, 8GB RAM). They are identically. On all of them an additional Jibri node got installed.
All machines except one of them are working properly. One of them takes all the memory, then takes all the swap and then crashes. I also reinstalled the system, still same issue. You got an idea why this happens? In the ffmpeg log there is just Last output line: [alsa @ 0x564859e614c0] ALSA buffer xrun.

Seems like ffmpeg eats it completly.
https://prnt.sc/16fftlv

Still climbing... always on a different machine. Sometimes one machine, sometimes two, sometimes three.

I experienced something really weird. I got four machines, all machines got the same specs (4 Cores, 8GB RAM). They are identically. On all of them an additional Jibri node got installed. All machines except one of them are working properly. One of them takes all the memory, then takes all the swap and then crashes. I also reinstalled the system, still same issue. You got an idea why this happens? In the ffmpeg log there is just Last output line: [alsa @ 0x564859e614c0] ALSA buffer xrun. Seems like ffmpeg eats it completly. https://prnt.sc/16fftlv Still climbing... always on a different machine. Sometimes one machine, sometimes two, sometimes three.

timowevel1 commented

2021-06-23 09:41:09 +00:00

(Migrated from github.com)

Seems like many people got the issue, I would like to switch to another Jibri version. Is that possible in any way?

timowevel1 commented

2021-06-23 10:29:54 +00:00

(Migrated from github.com)

Okay, seems like the CPU cannot process it fast enough, although there are 10 cores. Then it feeds up the memory. I set down the resolution to 720p and it works, but now only a quarter of the screen is captured, chrome is still at 1080p. Any way to change that also?

Ark74 commented

2021-06-23 15:51:14 +00:00

(Migrated from github.com)

I got four machines, all machines got the same specs (4 Cores, 8GB RAM).

Are they virtualized sharing resources on the same physical machine?

One of them takes all the memory, then takes all the swap and then crashes.

This sounds very much like a hardware issue, lack of CPU speed.

Okay, seems like the CPU cannot process it fast enough, although there are 10 cores.

It doesn't matter how many cores you have, if the cpu speed is not enough to process the input, it will irremediably fail.

I've read this happens on servers virtualizing several VM to run jibris on each one, this is possible but (I would) not recommended (it).

I would like to switch to another Jibri version.

Stable is most of the times the most "stable" (pun intended) version, sure you can pick the version you want from the available ones on the repository you have enabled.
If you installed using our script that repository is stable, check if that's what you need.

Here what's available there,

apt-cache madison jibri
     jibri | 8.0-93-g51fe7a2-1 | http://download.jitsi.org stable/ Packages
     jibri | 8.0-83-g204354d-1 | http://download.jitsi.org stable/ Packages
     jibri | 8.0-61-g99288dc-1 | http://download.jitsi.org stable/ Packages
     jibri | 8.0-53-ga574be9-1 | http://download.jitsi.org stable/ Packages
     jibri | 8.0-34-gd133175-1 | http://download.jitsi.org stable/ Packages
     jibri | 8.0-14-g0ccc3f6-1 | http://download.jitsi.org stable/ Packages
     jibri | 8.0-0-ge9fa56a-1 | http://download.jitsi.org stable/ Packages

You can go beyond and look if unstable suits you better, be careful enabling unstable though, so you only upgrade jibri.
Cheers!

> I got four machines, all machines got the same specs (4 Cores, 8GB RAM). Are they virtualized sharing resources on the same physical machine? > One of them takes all the memory, then takes all the swap and then crashes. This sounds very much like a hardware issue, lack of CPU speed. > Okay, seems like the CPU cannot process it fast enough, although there are 10 cores. It doesn't matter how many cores you have, if the cpu speed is not enough to process the input, it will irremediably fail. I've read this happens on servers virtualizing several VM to run jibris on each one, this is possible but (I would) not recommended (it). > I would like to switch to another Jibri version. Stable is most of the times the most "stable" (pun intended) version, sure you can pick the version you want from the available ones on the repository you have enabled. If you installed using our script that repository is stable, check if that's what you need. Here what's available there, ``` apt-cache madison jibri jibri | 8.0-93-g51fe7a2-1 | http://download.jitsi.org stable/ Packages jibri | 8.0-83-g204354d-1 | http://download.jitsi.org stable/ Packages jibri | 8.0-61-g99288dc-1 | http://download.jitsi.org stable/ Packages jibri | 8.0-53-ga574be9-1 | http://download.jitsi.org stable/ Packages jibri | 8.0-34-gd133175-1 | http://download.jitsi.org stable/ Packages jibri | 8.0-14-g0ccc3f6-1 | http://download.jitsi.org stable/ Packages jibri | 8.0-0-ge9fa56a-1 | http://download.jitsi.org stable/ Packages ``` You can go beyond and look if unstable suits you better, be careful enabling unstable though, so you only upgrade jibri. Cheers!

timowevel1 commented

2021-06-23 18:59:25 +00:00

(Migrated from github.com)

Yes you are right. What I did is setting the resolution to 720p. Also in xorg. It is shared hosting, the CPU should be able to handle it in terms of single core speed, but like you said, it is shared..

Jibri eating all memory #64