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

work_mem value can be bad #38

Open
roger-rainey opened this issue Mar 5, 2019 · 11 comments
Open

work_mem value can be bad #38

roger-rainey opened this issue Mar 5, 2019 · 11 comments
Labels
bug Something isn't working
Milestone

Comments

@roger-rainey
Copy link

The code that calculates work_mem can produce a value that is below the minimum threshold of 64kB. This will prevent timescale/postgress from starting. I have experienced this issue deploying to a k8s node w/ 32 Cores and 120GB Ram. The output from timescale-tune was 41kB which causes postgres to fail to start.

@RobAtticus
Copy link
Member

Yikes, that's no good. Did you set any other flags I should know about?

Will definitely look to push a fix ASAP

@RobAtticus RobAtticus added the bug Something isn't working label Mar 5, 2019
@RobAtticus RobAtticus added this to the 0.4.2 milestone Mar 5, 2019
@RobAtticus
Copy link
Member

RobAtticus commented Mar 5, 2019

I ask because when I try

timescaledb-tune --memory=120GB --cpus=32

I get this for memory settings

Recommendations based on 120.00 GB of available memory and 32 CPUs for PostgreSQL 11
shared_buffers = 30GB
effective_cache_size = 90GB
maintenance_work_mem = 2047MB
work_mem = 19660kB

So I wonder how it ended with 64KB

EDIT: Fixed memory flag

@roger-rainey
Copy link
Author

roger-rainey commented Mar 5, 2019 via email

@RobAtticus
Copy link
Member

Happy to correct the issue with it returning invalid values, but I am a bit worried that is is misreading your settings since it should not be giving 41KB for the given parameters (120GB RAM, 32 CPUs).

It would be useful if you could run the following commands from inside the container:

cat /sys/fs/cgroup/memory/memory.limit_in_bytes

and

free -m | grep 'Mem' | awk '{print $2}'

Thanks for the bug report

@roger-rainey
Copy link
Author

roger-rainey commented Mar 5, 2019 via email

@RobAtticus RobAtticus reopened this Mar 8, 2019
@RobAtticus
Copy link
Member

This got closed by the merge but there seems to be another problem at play here.

Specifically, 268435456 is only ~268MB, so your settings are based off that rather than the 120GB actually available on the machine. Do you have any insight as to why the machine would be giving that as the limit?

@RobAtticus
Copy link
Member

bump @roger-rainey

@roger-rainey
Copy link
Author

roger-rainey commented Mar 12, 2019 via email

@LeeHampton
Copy link

@roger-rainey That's intriguing. The cgroups memory.limit_in_bytes should refer to the maximum memory allocated to the container, not the minimum requested. I could see it being possible that the two would match up if the node the container is scheduled on only has request_memory available, but with such a specific number that seems kind of weird.

Would you mind posting your k8s configuration for this pod, and any other information you have about resource utilization on the node your pod is on?

If it seems like there's still more than request_memory available, I might have to do a deeper dive on how the cgroups memory limits get set when request settings are specified in k8s.

@RobAtticus
Copy link
Member

One other useful bit of info might be the output of

cat /sys/fs/cgroup/memory/memory.stat

@RobAtticus
Copy link
Member

@roger-rainey Did you have any follow up on this re: @LeeHampton 's comment?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants