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

Investigate massive memory leak #17

Closed
spaghettidba opened this issue Aug 2, 2018 · 2 comments
Closed

Investigate massive memory leak #17

spaghettidba opened this issue Aug 2, 2018 · 2 comments

Comments

@spaghettidba
Copy link
Owner

When running for 15 minutes or more, it ends up using a lot of memory. Looks like Strings are the most allocated objects (sql statements).

@spaghettidba
Copy link
Owner Author

Reduced memory usage by discarding already saved normalized queries and keeping only the Int64 hash. See commit 547463a

Might not be enough for the cases where the queries are extremely volatile. One factor that might be driving the volatility is TVPs, where the number of values captured in the incoming workload is extremely varying and leads to masive INSERT...VALUES statements of different sizes, when it should be recording only the call to the TVP instead.

@spaghettidba spaghettidba changed the title Invetigate massive memory leak Investigate massive memory leak Aug 27, 2018
@spaghettidba
Copy link
Owner Author

The memory leak was due to events queuing up in the listener, so I implemented a cache on disk to reduce memory consumption

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

1 participant