Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make memory tuning cgroups v2 compatible #262

Merged
merged 1 commit into from
Jul 1, 2024
Merged

Conversation

iarenaza
Copy link
Contributor

The old implementation only checked the sysfs files corresponding to cgroups v1. Most Linux distribution kernels have switched to cgroups v2 several years ago, which uses a different set of paths for various settings (memory limits included).

The net effect of the old implementation was that it completely ignored the memory limits, if the container was run in a kernel with cgroups v2 (in those kernels cgroups v1 are disabled by default).

The old implementation only checked the sysfs files corresponding to
cgroups v1. Most Linux distribution kernels have switched to cgroups
v2 several years ago, which uses a different set of paths for various
settings (memory limits included).

The net effect of the old implementation was that it completely
ignored the memory limits, if the container was run in a kernel with
cgroups v2 (in those kernels cgroups v1 are disabled by default).
@CLAassistant
Copy link

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.

1 similar comment
@CLAassistant
Copy link

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.

@svenklemm
Copy link
Member

@iarenaza could you please sign the contributor license agreement.

@svenklemm svenklemm merged commit 84ed6a2 into timescale:main Jul 1, 2024
0 of 10 checks passed
@udesaiitrs
Copy link

Hello, this change seems to break the TS_TUNE base script if run locally. I.e. we see errors like this:

timescale> /docker-entrypoint.sh: sourcing /docker-entrypoint-initdb.d/000_install_timescaledb.sh
timescale> CREATE EXTENSION
timescale> 2024-07-02 00:22:27.628 UTC [57] ERROR:  TimescaleDB background worker connected to template database, exiting
timescale> CREATE EXTENSION
timescale> 
timescale> /docker-entrypoint.sh: running /docker-entrypoint-initdb.d/001_timescaledb_tune.sh
timescale> 2024-07-02 00:22:27.630 UTC [35] LOG:  background worker "TimescaleDB Background Worker Scheduler" (PID 57) exited with exit code 1
timescale> /docker-entrypoint-initdb.d/001_timescaledb_tune.sh: line 42: [: max: integer expression expected

This was run on an M3 mac. Any ideas why this may be happening?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants