HPCC-32764 Periodically log information about cpu-throttling

[ghalliday]

Type of change:

• This change is a bug fix (non-breaking change which fixes an issue).
• This change is a new feature (non-breaking change which adds functionality).
• This change improves the code (refactor or other change that does not change the functionality)
• This change fixes warnings (the fix does not alter the functionality or the generated code)
• This change is a breaking change (fix or feature that will cause existing behavior to change).
• This change alters the query API (existing queries will have to be recompiled)

Checklist:

• My code follows the code style of this project.
  • My code does not create any new warnings from compiler, build system, or lint.
• The commit message is properly formatted and free of typos.
  • The commit message title makes sense in a changelog, by itself.
  • The commit is signed.
• My change requires a change to the documentation.
  • I have updated the documentation accordingly, or...
  • I have created a JIRA ticket to update the documentation.
  • Any new interfaces or exported functions are appropriately commented.
• I have read the CONTRIBUTORS document.
• The change has been fully tested:
  • I have added tests to cover my changes.
  • All new and existing tests passed.
  • I have checked that this change does not introduce memory leaks.
  • I have used Valgrind or similar tools to check for potential issues.
• I have given due consideration to all of the following potential concerns:
  • Scalability
  • Performance
  • Security
  • Thread-safety
  • Cloud-compatibility
  • Premature optimization
  • Existing deployed queries will not be broken
  • This change fixes the problem, not just the symptom
  • The target branch of this pull request is appropriate for such a change.
• There are no similar instances of the same problem that should be addressed
  • I have addressed them here
  • I have raised JIRA issues to address them separately
• This is a user interface / front-end modification
  • I have tested my changes in multiple modern browsers
  • The component(s) render as expected

Smoketest:

• Send notifications about my Pull Request position in Smoketest queue.
• Test my draft Pull Request.

Testing:

[github-actions]

Jira Issue: https://hpccsystems.atlassian.net//browse/HPCC-32764

Jirabot Action Result:
Workflow Transition To: Merge Pending
Updated PR

[mckellyln]

On my system and on the Azure LXC containers I don't think you need to get the cgroup you are in ?, if you read from /sys/fs/cgroup/cpu/cpu.stat I think it should be for the cgroup you are currently in.
I mean I think its ok to do this - but in LXC I don't think the current cgroup name is in /proc/self/cgroup so it may be better to just try and read from /sys/fs/cgroup/cpu/cpu.stat ? Or maybe do this if the current cgroup is empty ?
And the time string I see is "throttled_time" (in ns) so probably need to check for both.

[ghalliday]

On my system and on the Azure LXC containers I don't think you need to get the cgroup you are in ?, if you read from /sys/fs/cgroup/cpu/cpu.stat I think it should be for the cgroup you are currently in. I mean I think its ok to do this - but in LXC I don't think the current cgroup name is in /proc/self/cgroup so it may be better to just try and read from /sys/fs/cgroup/cpu/cpu.stat ? Or maybe do this if the current cgroup is empty ? And the time string I see is "throttled_time" (in ns) so probably need to check for both.

Running on ubuntu 22.04 /sysd/fs/cgroup/cpu.stat does not contain the any throttled information.

Please see next commit

[mckellyln]

I tested and it looks good on the Azure LXC containers.

On my Ubuntu system, with v1, if I -

sudo cgcreate -g cpu:/cgtest

Then /prof/self/cgroup shows the cgroup name on the cpu,cpuacct line, not on the 0::/ line, as in -

cat /proc/self/cgroup
13:misc:/
12:pids:/user.slice/user-1847.slice/user@1847.service
11:cpu,cpuacct:/cgtest
10:freezer:/
9:rdma:/
8:net_cls,net_prio:/
7:perf_event:/
6:cpuset:/
5:memory:/user.slice/user-1847.slice/user@1847.service
4:hugetlb:/
3:devices:/user.slice
2:blkio:/user.slice
1:name=systemd:/user.slice/user-1847.slice/user@1847.service/gnome-launched-org.codeberg.dnkl.foot.desktop-227483.scope
0::/user.slice/user-1847.slice/user@1847.service/gnome-launched-org.codeberg.dnkl.foot.desktop-227483.scope

So I think its ok - as we will then read from /sys/fs/cgroup/cpu/cpu.stat

[mckellyln]

Looks good.
Tested ok on v1 also.