-
Notifications
You must be signed in to change notification settings - Fork 61
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
Conversation
There was a problem hiding this 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).
Regarding |
There was a problem hiding this 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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
|
||
// 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 |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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.
// Leak the old mapping as there might be concurrent readers. | ||
std::mem::forget(old_map); |
There was a problem hiding this comment.
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.
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.