Skip to content

revert read-only mmap limit and seek compaction - #186

Open
willcl-ark wants to merge 49 commits into
masterfrom
restore-kDefaultMmapLimit
Open

revert read-only mmap limit and seek compaction#186
willcl-ark wants to merge 49 commits into
masterfrom
restore-kDefaultMmapLimit

Conversation

@willcl-ark

@willcl-ark willcl-ark commented Jun 4, 2026

Copy link
Copy Markdown

Test reverting read-only mmap limit and seek compaction together

willcl-ark and others added 30 commits June 4, 2026 05:51
Adds build configuration, benchmarking CI workflows, Python
dependencies, plotting tools, and documentation for benchcoin.

Co-authored-by: David Gumberg <davidzgumberg@gmail.com>
Co-authored-by: Lőrinc <pap.lorinc@gmail.com>
- Fix empty chart: use get_chart_data() instead of to_dict() so JS
  filters can match config strings ("450", "32000") instead of objects
- Capture machine specs on self-hosted runner during build job and pass
  via --machine-specs flag to nightly append, instead of detecting on
  the ubuntu-latest publish runner
Run LogParser + PlotGenerator from bench/analyze.py during artifact
copying to produce static PNG charts from debug.log files. This
pre-generates the same 11 chart types that were previously rendered
client-side via JavaScript.

Changes to report.py:
- Import HAS_MATPLOTLIB, LogParser, PlotGenerator from bench.analyze
- _copy_network_artifacts: generate plots after each debug.log with
  "{network}-{name}" prefix (e.g. "450-uninstrumented-pr")
- _copy_artifacts: generate plots for single-directory mode, including
  when input_dir == output_dir
- _prepare_graphs_data: add "plots" key with relative paths to PNGs
- generate(): reorder to copy artifacts before HTML rendering so
  _prepare_graphs_data can find the generated plot files

Plot generation is guarded by HAS_MATPLOTLIB for graceful fallback
when matplotlib is unavailable.
The pr-report.html template previously included debug-log-charts.html
which fetched multi-hundred-MB debug.log.gz files in the browser,
decompressed them with pako.js, parsed every line, and rendered 11
Plotly charts client-side. This made report pages unresponsive.

Now that report.py pre-generates the charts as static PNGs:
- pr-report.html: replace the debug-log-charts.html include with an
  img loop over graph.plots, using loading="lazy"
- debug-log-charts.html: delete (344 lines of client-side JS)
- base.html: remove pako.js and Plotly CDN scripts (both are
  independently included by pr-chart.html and nightly-chart.html
  via their own script tags)

The debug.log download link is preserved.
Rewrite to document the TOML config + matrix entry workflow,
removing stale references to the old two-commit comparison CLI,
--datadir requirement, profiles, and BENCH_DATADIR env var.
Debug logs were consuming 388MB on gh-pages. They are already uploaded
as CI artifacts with 90-day retention during benchmark runs.

- Remove gzip compression and copying of debug logs in report generation
- Remove debug log extraction in publish-results workflow
- Replace per-graph "Download debug.log" links with a single link to
  the CI run page where artifacts can be downloaded
- Keep matplotlib plot generation from debug logs (plots are still
  generated during report phase, just the raw logs aren't published)
The PR comment with result links was posted before GitHub Pages
finished deploying, leading to broken links. Add a wait-for-pages
job that polls for the pages-build-deployment run matching our
exact gh-pages commit, then blocks until it completes.
Previously, prune=10000 was causing flushes of the UTXO set when block
pruning was taking please, resulting in logs like:

❯ zcat 32000-instrumented-pr-debug.log.gz | rg UTXO
2026-02-12T07:22:57Z * Using 31990.0 MiB for in-memory UTXO set (plus up to 286.1 MiB of unused mempool space)
2026-02-12T07:28:51Z [warning] Flushing large (2 GiB) UTXO set to disk, it may take several minutes
2026-02-12T07:33:10Z [warning] Flushing large (3 GiB) UTXO set to disk, it may take several minutes
2026-02-12T07:37:23Z [warning] Flushing large (4 GiB) UTXO set to disk, it may take several minutes
2026-02-12T07:42:03Z [warning] Flushing large (4 GiB) UTXO set to disk, it may take several minutes
2026-02-12T07:46:34Z [warning] Flushing large (5 GiB) UTXO set to disk, it may take several minutes
2026-02-12T07:51:10Z [warning] Flushing large (6 GiB) UTXO set to disk, it may take several minutes
2026-02-12T07:55:57Z [warning] Flushing large (7 GiB) UTXO set to disk, it may take several minutes
2026-02-12T08:00:35Z [warning] Flushing large (8 GiB) UTXO set to disk, it may take several minutes
2026-02-12T08:05:16Z [warning] Flushing large (8 GiB) UTXO set to disk, it may take several minutes
2026-02-12T08:10:00Z [warning] Flushing large (8 GiB) UTXO set to disk, it may take several minutes
2026-02-12T08:14:36Z [warning] Flushing large (8 GiB) UTXO set to disk, it may take several minutes
2026-02-12T08:16:47Z [warning] Flushing large (8 GiB) UTXO set to disk, it may take several minutes

and generally interrupting benchmarking. Remove this effect by setting
prune to such a high value it will never trigger.

Prune is **required** to permit us to continue syncing from a pruned
datadir.
@willcl-ark
willcl-ark force-pushed the master branch 7 times, most recently from 3a50668 to d6ca486 Compare June 30, 2026 04:57
@willcl-ark
willcl-ark force-pushed the master branch 7 times, most recently from d17eb87 to 596c871 Compare July 8, 2026 04:09
@willcl-ark
willcl-ark force-pushed the master branch 6 times, most recently from 34ae8da to f1180c9 Compare July 15, 2026 03:53
@willcl-ark
willcl-ark force-pushed the master branch 5 times, most recently from 53345d8 to 616e2e3 Compare July 24, 2026 04:08
@willcl-ark
willcl-ark force-pushed the master branch 5 times, most recently from 4aaf9e7 to 2b34f9d Compare July 30, 2026 03:51
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.

1 participant