-
Notifications
You must be signed in to change notification settings - Fork 23
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
Marshmallow Memory Leak #105
Comments
haven't tested this yet but reimplementing del is supposed to fix this issue |
OK a bit more info to go on... Here is the trace malloc output for the top memory using items.
|
Based on the info in marshmallow/#1934 Everytime We should use class-based caching here. Opening a fork to try a few thing.
|
Found this issue as well but appears to be resolved: |
@SoundsSerious nice work. Looking forward to the results. |
OK. Testing this out now, but it appears to save a bunch of memory on access. the retreiving class commands get called quite a lot so I feel that is promising.
|
I dont think its too harmful to remove the **kwargs since "only" was the only option used |
This certainly seems to have had an effect, the top memory usage (ala tracemalloc) is no longer marshmallow related, so that's promising. Will continue investigating. |
So just testing on my application workload I can report that on a high level per item basis this seems to improve memory consumption by 2x, but there is still a growth issue. I'd say it also runs about 25% faster too. I guess I'll have to figure out how to PR from a fork now :) |
Looks like progress but there is still some kind of growing memory, here's a stack trace of items after about an hour:
|
Looks like this is working for me in the new version |
@kashifpk finding a pretty significant memory leak at scale with the marshmallow library.
marshmallow-code/marshmallow#1943
certainly seems like that lib is the source of a few problems.
The text was updated successfully, but these errors were encountered: