Size the gr buffer pool to the dataset and profile LSQB on SF1 - #53
Open
tamnd wants to merge 2 commits into
Open
Size the gr buffer pool to the dataset and profile LSQB on SF1#53tamnd wants to merge 2 commits into
tamnd wants to merge 2 commits into
Conversation
Profiling gr on the real LDBC SNB SF1 graph (3.0M nodes, 17.2M edges, a 1 GB database) showed both the bulk load and the heavy queries bottlenecked on the pager. A quarter of the load sat in buffer-pool eviction, and the slowest query's stack was dominated by pread re-reading store pages the pool had just dropped. The cause was gr's default 1024-page pool, about 4 MB, holding 0.4% of a 1 GB database resident. Size the pool to the data instead. The adapter computes a page count from the database file size on disk (and from the input CSV bytes for the bulk loader's build pool), with headroom and a memory cap, and passes it through gr's new MaxPoolPages option. An explicit pool_pages config value overrides the auto-sizing; pool_max_bytes overrides the cap. Sizing the pool to hold the working set drops the heaviest measured query from 15.1s to 8.0s, pure removed disk I/O. Add TestProfileLSQBOnSF1, gated behind GRAPH_BENCH_SF1: it loads SF1 into gr once (caching the loaded database so later runs skip the load), times every LSQB query, streams each p50 and count, takes ONLY/SKIP substring filters to isolate one query, and writes a query-phase CPU profile. It is the inner loop for the planner work the profile points to next, where the slow queries are now CPU-bound in the join and enumeration with no I/O left.
The profiler shows which query is slow; this shows why. TestExplainLSQBOnSF1 prints gr's chosen plan for each LSQB query on the real SF1 graph, so a query that falls out of the fused count into a materializing Intersect is visible in the plan tree rather than inferred from the timing. Both it and the profiler take GRAPH_BENCH_ONLY and GRAPH_BENCH_SKIP so a single pathological query can be explained or stepped around in isolation.
Owner
Author
|
Leaving this open but it will not merge as it stands. Every file it touches except the test lives in It also does not build against the current tamnd/gr, which does not have The profiling result stands on its own and is worth keeping. Landing it means writing a gr engine against the v0.3 SPI and carrying the pool sizing into it, which is its own change. Say the word and I will do that as a fresh PR. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Profiling gr on the real LDBC SNB SF1 graph (3.0M nodes, 17.2M edges, a 1 GB database) found both the bulk load and the heavy LSQB queries bottlenecked on the pager, not on the query plan.
A quarter of the load sat in buffer-pool eviction, and the slowest query's stack was dominated by
preadre-reading store pages the pool had just dropped.The cause was gr's default 1024-page pool, about 4 MB, holding 0.4% of a 1 GB database resident. A 4 MB cache in front of a 1 GB database is a misconfiguration, not a number worth reporting.
This sizes the pool to the data. The adapter computes a page count from the database file size on disk (and from the input CSV bytes for the bulk loader's build pool), with a quarter headroom and a 4 GiB cap, and passes it through gr's new
MaxPoolPagesoption.pool_pagesoverrides the auto-sizing with a fixed count;pool_max_bytesoverrides the cap.Sizing the pool to hold the working set drops the heaviest measured query from 15.1s to 8.0s, a 1.9x win that is pure removed disk I/O.
Depends on gr PR #229, which exposes
MaxPoolPagesongr.Optionsandloader.Options(the adapter builds against the local gr replace).Adds
TestProfileLSQBOnSF1, gated behindGRAPH_BENCH_SF1:GRAPH_BENCH_ONLY/GRAPH_BENCH_SKIPcomma-separated substring filters to isolate or step around one query while it is optimizedGRAPH_BENCH_QUERY_PROFILEis setAfter the pool fix the slow queries (q3, q6, q7) sample with zero
pread: they are now fully CPU-bound in the join and enumeration.The bottleneck moved from the pager to the planner, which is the next frontier and a separate change. Full write-up in notes/Spec/2060/bench/implementation/lsqb-sf1-buffer-pool-profiling.md.