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

OutOfMemory exception with low system memory usage #359

Open
mskarlin opened this issue Sep 27, 2024 · 3 comments
Open

OutOfMemory exception with low system memory usage #359

mskarlin opened this issue Sep 27, 2024 · 3 comments

Comments

@mskarlin
Copy link

We're struggling to diagnose an issue where we are instantiating several Index objects (built on the same shared directory) in asynchronous coroutines, and setting the following stack trace:

ValueError: Failed to open file for read: 'IoError { io_error: Os { code: 12, kind: OutOfMemory, message: "Cannot allocate memory" }, filepath: "<index file path>" }

We have a relatively small index (~5Gb), and even with several instantiated Index objects, the system RAM usage is low (on a machine with 60Gb of memory, we're only seeing ~3Gb used). But when running with 4 concurrent coroutines we see the above issue.

In trying to reproduce, I made a tiny index with ~100 files, and ran 100 simultaneous coroutines, each of which with their own Index object, and was not able to reproduce the error.

Do you have any suggestions on what to investigate next?

@cjrh
Copy link
Collaborator

cjrh commented Sep 28, 2024

We're running with thousands of different indexes on a shared box, but we're using process pools instead of your async handling. We don't see memory growth in these long lived processes (that access different indexes over time), but to be fair we have not yet upgraded to 0.22.

As for suggestions, this might be a good application of the FIL memory profiler: https://pythonspeed.com/fil/docs/index.html

In essence, you can run your application in a staging environment with a copy of your "real" index, do what you need to do to make memory grow, and then when memory is high, kill the process. The memory profiler will dump a file showing where allocations were held. You get a flamegraph view:

https://pythonspeed.com/fil/docs/interpreting-output.html

@cjrh
Copy link
Collaborator

cjrh commented Sep 28, 2024

It would also be good document more specifics about your situation, i.e., package version, platform, etc.

@cjrh
Copy link
Collaborator

cjrh commented Oct 2, 2024

There was an actual memory leak a few versions back, in PyO3: PyO3/pyo3#3285. So it is important to know which version you're using. There are also a few other memory leak issues on the PyO3 tracker, so you might have a look there too to see if anything might be affecting you.

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

No branches or pull requests

2 participants