build: use FIFO scheduler in bbb-webrtc-sfu

[prlanzarin]

What does this PR do?

• build: use FIFO scheduler in bbb-webrtc-sfu
  • This commit puts bbb-webrtc-sfu in the FIFO scheduling policy (same as
    bbb-html5). Also bumps bbb-html5 nice level up to 18 and sets SFU to
    nice 19 (so bbb-html5 has some advantage when push comes to shove).

Closes Issue(s)

Closes #

Motivation

bbb-webrtc-sfu (and mediasoup) are running in the CFS scheduler which
means it has to compete with (much) lower priority tasks like
presentation conversion, recording processing, [...]
Since it encompasses an RTC application which also handles audio, it
should be at least on the same scheduling policy as FS/bbb-html5 - and
that should be safer now with mediasoup which has a lower footprint
(and generates lower CPU noise overall).

This can be improved further by using per-process priorities in SFU.
Ideally we'd want mediasoup audio workers and mcs-core to be the same
priority as FS (so higher than bbb-html5), but the rest of them
(video/screen workers) to be the same or lower than bbb-html5.
For future reference:

• bigbluebutton/bbb-webrtc-sfu@3e24512
• bigbluebutton/bbb-webrtc-sfu@66d443d

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[schrd]

Just an idea: Processes belonging to a service can be grouped by using systemd slices. That way a group of processes could be prioritized/limited not matter how many processes exist in a group. That way you can limit for example the cpu consumption of all html5 processes no matter how many are configured. And you can weight groups of processes, like all bbb-html5 processes to all bbb-webrtc-sfu and to all freeswitch ones.

A slice hierarchy might look like this:

• bigbluebutton.slice
  • bigbluebutton-media.slice
    • audio.slice
      • freeswitch.service
      • bbb-webrtc-sfu-audio.service
    • video.slice
      • bbb-webrtc-sfu-video.service
  • bigbluebutton-nomedia.slice
    • bbb-apps-akka.service
    • bbb-fsesl-akka.service
    • bbb-web.service

See https://www.man7.org/linux/man-pages/man5/systemd.slice.5.html and https://www.man7.org/linux/man-pages/man5/systemd.resource-control.5.html

[prlanzarin]

Just an idea: Processes belonging to a service can be grouped by using systemd slices. That way a group of processes could be prioritized/limited not matter how many processes exist in a group. That way you can limit for example the cpu consumption of all html5 processes no matter how many are configured. And you can weight groups of processes, like all bbb-html5 processes to all bbb-webrtc-sfu and to all freeswitch ones.

A slice hierarchy might look like this:

* `bigbluebutton.slice`
  
  * `bigbluebutton-media.slice`
    
    * `audio.slice`
      
      * `freeswitch.service`
      * `bbb-webrtc-sfu-audio.service`
    * `video.slice`
      
      * `bbb-webrtc-sfu-video.service`
  * `bigbluebutton-nomedia.slice`
    
    * `bbb-apps-akka.service`
    * `bbb-fsesl-akka.service`
    * `bbb-web.service`

See https://www.man7.org/linux/man-pages/man5/systemd.slice.5.html and https://www.man7.org/linux/man-pages/man5/systemd.resource-control.5.html

Neat. From the top of your head do you know if slices have a neat way of handling prioritization of child processes? Or does that only apply easily to parent processes?

[schrd]

Neat. From the top of your head do you know if slices have a neat way of handling prioritization of child processes? Or does that only apply easily to parent processes?

I don't know if I understood https://systemd.io/CGROUP_DELEGATION/ correctly. But I think it is possible to move processes into a systemd scope that belongs to a different slice than the managing process which forks off the processes. I found this one but did not try if it works: https://unix.stackexchange.com/questions/525740/how-do-i-create-a-systemd-scope-for-an-already-existing-process-from-the-command

You can inspect the cgroup tree in your system by running systemd-cgls.

[prlanzarin]

I'll open a follow up issue for the improvements discussed here.