duckdb: Memory leak, source unknown
What happens?
We have a Java service that operates an in-memory DuckDB database for long periods of time, creating, loading, and dropping tables all the while. We have observed what we believe to be a memory leak, but have so far been unsuccessful in locating the source of the leak.
To Reproduce
We’ve written a minimal reproduction and shared it as a GitHub repository. The reproduction runs for a specified period of time. During execution it creates and loads tables at a rate of 5 tables per second. It drops tables as necessary to maintain a “live” set of 100 tables. Tables are loaded using the Appender class.
The reproduction code itself doesn’t maintain any notable, long-term state beyond a primary DuckDBConnection object.
Environment (please complete the following information):
- OS: Ubuntu Linux 16.04
- DuckDB Version: 0.3.2
- DuckDB Client: Java
Before Submitting
- Have you tried this on the latest
masterbranch?
- Python:
pip install duckdb --upgrade --pre - R:
install.packages("https://github.com/duckdb/duckdb/releases/download/master-builds/duckdb_r_src.tar.gz", repos = NULL) - Other Platforms: You can find binaries here or compile from source.
- Have you tried the steps to reproduce? Do they include all relevant data and configuration? Does the issue you report still appear there?
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Comments: 19 (10 by maintainers)
Commits related to this issue
- Fix #3291: delete root entries after a catalog entry is deleted and no more transactions can reference it — committed to Mytherin/duckdb by Mytherin 2 years ago
- Merge pull request #3323 from Mytherin/issue3291 Fix #3291: delete root entries after a catalog entry is deleted and no more transactions can reference it — committed to duckdb/duckdb by Mytherin 2 years ago
@Mytherin early investigations seem to indicate that this has fixed most, if not all, of the leak for our reproduction case. 👍