-
Notifications
You must be signed in to change notification settings - Fork 142
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
Automatic h5_garbage_collect() garbage collection #1186
Comments
Could you see if invoking https://github.com/JuliaIO/HDF5.jl/blob/master/src%2Fapi%2Ffunctions.jl#L67 |
I did a quick test, including this in the loop seems to stabilize the memory usage. |
I would consider this to be a workaround for now. I need to investigate further how well this is documented upstream in HDF5 itself, and when would be appropriate to call this automatically. Perhaps a |
Ok, Ill keep this ticket open in that case |
Ideally we should call this when the Julia GC is invoked, but we probably don't want to call it every time an object is freed. One way to do this would be to add a callback into the Julia GC (so it gets called after the Julia GC is invoked). This can be done by calling |
In this case with the do syntax, I think we could call thr HDF5 GC when closing the "file" when we know that file is backed by allocated memory. |
Good afternoon,
There might be a memory leak in HDF5, related to using
driver=Drivers.Core(; backing_store=false)
.I created a reduced exampled that can be reproduced as follows:
sudo docker run -it --memory=500m hdf5test:1.0
and copy the code ), it will be killed for OOM reason sooner or laterThe container memory will immediately jump close to the limit and stay there for a while, for higher memory cap, it will take longer for the container to be killed. Once the container is killed, to be sure it was due to memory, you can
docker inspect <containerid>
Best regards,
Christian Dengler
The text was updated successfully, but these errors were encountered: