feat: add cpu_shares to mastercontainer and sibling containers for better responsiveness under heavy load

[Copilot]

• Mastercontainer cpu_shares: 2048 (compose.yaml, readme.md, reverse-proxy.md, multiple-instances.md)
• 9 core containers in containers.json: cpu_shares: 1024 (apache, database, nextcloud, notify-push, redis, borgbackup, watchtower, harp, docker-socket-proxy)
• 9 optional/extra containers in containers.json: cpu_shares: 512 (collabora, talk, talk-recording, domaincheck, clamav, onlyoffice, imaginary, fulltextsearch, whiteboard)
• Default cpuShares in ContainerDefinitionFetcher.php: 512
• cpu_shares property added to containers-schema.json
• cpuShares field added to Container.php
• CpuShares applied in DockerActionManager.php

[Zoey2936]

same as with my comments to OOM-Killer

[szaimen]

@copilot please change the default in ContainersDefinitionFetchter from 1024 to 512 and reduce all added values by factor 2

[Copilot]

@copilot please change the default in ContainersDefinitionFetchter from 1024 to 512 and reduce all added values by factor 2

Done in c128f29. Default changed to 512, container values reduced to 1024, and mastercontainer to 2048.

[derStephan]

Wouldn't it make sense to raise Talk's priority? Talk - or better the TURN server in it - is the only application that has real-time requirements. So under heavy load, this should be prioritized over everything else because everything else can simply wait. In the settings given in the first comment, talk shares the lowest priority of 512 with all other containers.

And another thought. Setting the same high value for such a number of containers might gain nothing, because in case of load, all of those containers keep fighting for CPU time.

I'd suggest to define distinct values for each container, in the order of real-time requirements and responsiveness impact.