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

Use mmap IO for value tables #214

Merged
merged 18 commits into from
Jul 21, 2023
Merged

Use mmap IO for value tables #214

merged 18 commits into from
Jul 21, 2023

Conversation

arkpar
Copy link
Member

@arkpar arkpar commented Jul 18, 2023

This works much faster when performance is limited by OS page cache. When the database is relatively small and fits entirely in the page cache, making kernel calls becomes too expensive.
Also removed extra copy to a temp buffer when reading values from file.
Also optimized overlay layout a bit. The top level is a vec now instead of a hashmap.

@arkpar arkpar requested review from cheme and MattHalpinParity and removed request for cheme July 18, 2023 12:05
@arkpar arkpar requested a review from cheme July 18, 2023 16:40
Copy link
Collaborator

@cheme cheme left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lgtm,
I remember having a branch with a trait to be able to choose file or mmap depending on use case as in https://github.com/cheme/parity-db/blob/file_mmap2/src/file.rs.
There was some perf issue, but I was locking write on the mmap, maybe locking read as here, thing would have been good.
I remember bigger issue was grow, not exactly sure why but I ended up with https://github.com/cheme/parity-db/blob/3b49e8724f30573570faab9f8902ad7b65211bc1/src/file.rs#L420 at the time (madvise is missing and mflush is useless).

src/file.rs Show resolved Hide resolved
src/file.rs Outdated Show resolved Hide resolved
@arkpar
Copy link
Member Author

arkpar commented Jul 18, 2023

Regarding grow, it does take some time indeed to create a new mapping. mremap only works on linux. One solution is to simply reserve a lot of address space for each file with the initial mapping. Then, as file grows, this additional address space can be used without remapping. I've left this optimization for later though. Current version with creating a new map each time is quick enough.

Copy link
Collaborator

@cheme cheme left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

aarch64 test did fail, not sure why, I did not try to relaunch it (looks like it timeout, hope it is not an atomic aarch64 only hard to debug issue).

pub path: std::path::PathBuf,
pub capacity: AtomicU64,
pub id: TableId,
}

fn map_len(file_len: u64) -> usize {
file_len as usize + RESERVE_ADDRESS_SPACE
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wonder if we also should try to align the size?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm made is so that file size is always aligned.

src/log.rs Show resolved Hide resolved

// Use different value for tests to work around docker limits on the test machine.
#[cfg(test)]
const RESERVE_ADDRESS_SPACE: usize = 64 * 1024 * 1024; // 64 Mb
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wondering if this could be configurable (probably these kind of limitation might exist on some cloud infra).
Maybe even a bit more granular (eg more reserved for log).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'll give it a round of testing on the parity infrastructure. I've tested on my arm64 vm and had no issues.

@arkpar arkpar merged commit 3034715 into master Jul 21, 2023
6 checks passed
@arkpar arkpar deleted the arkpar/mmap-table branch July 21, 2023 10:57
Comment on lines +172 to +173
// Leak the old mapping as there might be concurrent readers.
std::mem::forget(old_map);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this leak not an issue? I'm trying to identify the root cause of #233 and this looks like a candidate.

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

Successfully merging this pull request may close these issues.

3 participants