Limit gProfiler memory & CPU usage

[Jongy]

The easiest way to place a hard limit on the memory used by gProfiler, as gProfiler is a privileged app, is to use cgroups. We have such API in granulate-utils - see this file. We can use it to place gProfiler in a cgroup & set its limit to e.g 1GB to ensure we don't grow too much, e.g due to https://github.com/Granulate/gprofiler/issues/528

[Jongy]

The same can be applied on CPU limits

[Creatone]

Hello @Jongy! I am interested in working on this issue. Can I be assigned to it?

[Jongy]

Hi @Creatone ! You're welcome to try it :)

Let's define an MVP:

• Only cgroups v1 support (cgroups v2 will be done later).
• gProfiler will check if it's already in a cgroup (this check is already done in move_to_cgroup for "predefined" ones, which are Docker/k8s/ECS. So we can just use the API of move_to_cgroup and handle the raised exception if we're already in a cgroup).
• The default limits should be as set in the k8s DaemonSet.
• Allow passing --limit-memory and --limit-cpu which override the defaults. Units are bytes for memory (int) and cores (float, 1 == 1 core) for CPU. If -1 is given it implies no limit, but you can still move to the cgroup, as this can help us do measurements of utilization, as explained in https://github.com/Granulate/gprofiler/issues/227. After this issue (#529), I want --log-usage to work for exe mode as well (i.e I expect this issue to resolve #227 as well).
• Allow passing --no-cgroups to avoid doing ANY cgroups changes (moving / changing limits etc). It's always helpful to have a kill switch.
• Try moving into cgroups & limiting as early as possible, but after the logger is initialized, so that you can log errors.
• If any error happens during cgroups handling, swallow it and log (i.e don't block gProfiler). Try to use the APIs from granulate-utils cgroups package. If things are missing, we should probably add them in granulate-utils (we can discuss that in this issue here, and then you can open a PR to granulate-utils as well).

Good luck :)