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

Improve memory available detection #1712

Closed
asyd opened this issue Jan 26, 2018 · 6 comments · Fixed by #3039
Closed

Improve memory available detection #1712

asyd opened this issue Jan 26, 2018 · 6 comments · Fixed by #3039

Comments

@asyd
Copy link

asyd commented Jan 26, 2018

In

TOTAL_MEMORY = psutil.virtual_memory().total
you use psutil to known the amount of memory available.

However, in the case of the worker is launched in a cgroup with a memory limitation (memory.limit_in_bytes) the value returned by psutil is the amount of the host, not the amount available in the cgroups, there fore the worker try to use more memory than it can and the linux kernel kill it.

@mrocklin
Copy link
Member

You can solve this manually by telling dask workers to limit their memory usage with --memory-limit NBYTES

To make this more automatic is there a nice way to get the cgroups memory limit from python with a library like psutil?

@asyd
Copy link
Author

asyd commented Jan 26, 2018

I'm looking for it!

@mrocklin
Copy link
Member

Any update here @asyd ?

@asyd
Copy link
Author

asyd commented Feb 22, 2018

Hi @mrocklin,

what do you think about asyd@e6f1883?

@mrocklin
Copy link
Member

Interesting. Is this accurate for all linux distributions, or do some systems behave differently?

@asyd
Copy link
Author

asyd commented Feb 22, 2018

Since it's a Linux kernel feature it should work on every linux distributions.

However, while this workaround will work on my use case (worker runs inside a docker container) I need to improve it to check if the worker runs on root cgroup or a subone by checking /prod/self/cgroup but I wanted have feedbacks before

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 a pull request may close this issue.

2 participants