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

TreeIndex slow memory reclamation #66

Closed
rsdy opened this issue Mar 3, 2022 · 5 comments
Closed

TreeIndex slow memory reclamation #66

rsdy opened this issue Mar 3, 2022 · 5 comments
Milestone

Comments

@rsdy
Copy link

rsdy commented Mar 3, 2022

It seems like TreeIndex will leak significant amounts of memory with large number of insertions. I'm trying to insert a few billion records into a TreeIndex, with periodically cleaning it, like so:

    let index = scc::TreeIndex::new();

    for records in files
        .into_iter()
        .filter_map(|file| LogRecord::<MyStruct>::load_cbor(&file).ok())
        .flatten()
    {
        index
            .insert(ts.clone(), scc::ebr::Arc::new(record))
            .ok()
            .unwrap();

        records_written += 1;

        /// ... do something

        if records_written % 1_000_000 == 0 {
            index.clear();
            println!("records_written: {}", records_written);
        }
    }

I can observe the memory use keeps climbing even though i call clear() to try to control it.

I'm using 0.6 for these tests.

@wvwwvwwv
Copy link
Owner

wvwwvwwv commented Mar 3, 2022

Thanks for reporting this. I've briefly tested the scenario, and it indeed seems problematic. Actually, it is not a leak, instead, ebr reclaims garbage instances way too slowly. I'll try to make memory reclaim faster..

wvwwvwwv added a commit that referenced this issue Mar 3, 2022
Add a test case whether `TreeIndex` leaks memory.
@wvwwvwwv
Copy link
Owner

wvwwvwwv commented Mar 3, 2022

It will take some time to fix the issue. Expediting memory reclamation is not as simple as I expected.

@wvwwvwwv
Copy link
Owner

wvwwvwwv commented Mar 5, 2022

The fix speeds memory reclamation up by a factor of 3; not quite satisfactory, that it is the best that I can get in short time. Hope that it will help.
=> Will be included in 0.6.1.

wvwwvwwv added a commit that referenced this issue Apr 2, 2022
traverse several leaf nodes on every node deletion to release strong
references earlier.
@wvwwvwwv
Copy link
Owner

wvwwvwwv commented Apr 2, 2022

more aggressive memory reclamation applied.
=> Will be included in 0.6.2.

@wvwwvwwv wvwwvwwv closed this as completed Apr 2, 2022
@wvwwvwwv
Copy link
Owner

Yet another node reclamation method will be implemented in 0.7.0.

@wvwwvwwv wvwwvwwv reopened this Apr 29, 2022
@wvwwvwwv wvwwvwwv added this to the SCC 0.7.0 milestone Apr 29, 2022
@wvwwvwwv wvwwvwwv changed the title TreeIndex memory leak TreeIndex slow memory reclamation Apr 29, 2022
@wvwwvwwv wvwwvwwv closed this as completed May 1, 2022
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