-
Notifications
You must be signed in to change notification settings - Fork 516
PagePool::{default -> new_for_test}
+ temporary hack for IN_MEMORY_CONFIG
/ test_index_scans
#2707
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
base: master
Are you sure you want to change the base?
Conversation
20d2cc3
to
464bbe4
Compare
464bbe4
to
cab6b01
Compare
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.
- Needs companion PR to fix internal tests.
- Should we be using a smaller page pool everywhere, not just in tests? Do the page pool metrics have anything useful to tell us here?
The code changes look fine and I'm willing to approve this, but I'm not super excited to merge it without knowing whether using the same smaller pool everywhere would win us two orders of magnitude of performance somehow.
cab6b01
to
ee91dbf
Compare
https://github.com/clockworklabs/SpacetimeDBPrivate/pull/1691
The metrics, if I'm reading them correctly, suggests that we were storing about 40k pages in the pool, whereas the limit is about 131k pages. Might be good to shrink to 4 GiB instead of 8 GiB as the default? But I would suggest that we do such changes in follow ups to unblock CI/other PRs. |
We decided to disable the page pool in the host for now. |
d3aa7b6
to
c160fe6
Compare
@coolreader18 the smoketests failing don't seem to have anything to do with this PR but look related to #2644? |
Description of Changes
First,
PagePool::default
is renamed toPagePool::new_for_test
to make sure::default()
isn't used anywhere.This was useful when debugging the issue.
Second,
IN_MEMORY_CONFIG
incrates/testing/src/modules.rs
is changed so thatpage_pool_max_size: Some(size_of::<Page>())
, which is the minimum possible. This makes the failures intest_index_scans
go away. On my i7-7700K/64GB the threshold for the test failing seems to be at1 << 26
but it passes on1 << 25
. As to why a page pool >= 64 MiB would cause such a slow down is unclear to me as of yet.Third, the default page pool size is now
Some(size_of::<Page>())
which effectively disables page pooling.API and ABI breaking changes
None
Expected complexity level and risk
1
Testing
This fixes a test.