safekeeper: add basic WAL ingestion benchmarks

[erikgrinaker]

Problem

We don't have any benchmarks for Safekeeper WAL ingestion.

Resolves #9339.
Blocked by #9614.

Summary of changes

Add some basic benchmarks for WAL ingestion, specifically for SafeKeeper::process_msg() (single append) and WalAcceptor (pipelined batch ingestion).

Checklist before requesting a review

• I have performed a self-review of my code.
• If it is a core feature, I have added thorough tests.
• Do we need to implement analytics? if so did you add the relevant metrics to the dashboard?
• If this PR requires public announcement, mark it with /release-notes label and add several sentences in this section.

Checklist before merging

• Do not forget to reformat commit message to not include the above checklist
  In

[github-actions]

5328 tests run: 5100 passed, 6 failed, 222 skipped (full report)

---

Failures on Postgres 17

• test_pg_regress[None]: release-x86-64, release-arm64, debug-x86-64
• test_pg_regress[4]: release-x86-64, release-arm64, debug-x86-64

# Run all failed tests locally:
scripts/pytest -vv -n $(nproc) -k "test_pg_regress[release-pg17-None] or test_pg_regress[release-pg17-None] or test_pg_regress[debug-pg17-None] or test_pg_regress[release-pg17-4] or test_pg_regress[release-pg17-4] or test_pg_regress[debug-pg17-4]"

Test coverage report is not available

_{The comment gets automatically updated with the latest test results
f4b8795 at 2024-11-03T17:25:29.676Z :recycle:}

[VladLazar]

LGTM, maybe Arseny could take a look as well for some more SK context?

[VladLazar]

Yeah, I expected this benchmark to measure tput. Does it not make sense to do that now?

[erikgrinaker]

Sure, I'll add it.

[erikgrinaker]

Added a separate wal_acceptor_throughput benchmark, with the intent that wal_acceptor measures the cost of ingesting trivial messages (i.e. per-message processing latency), while wal_acceptor_throughput measures bulk ingestion (typically IO-bound).

Smaller messages really kill throughput. Lower than 1 KB per message wasn't viable since the benchmark would take 30 minutes to ingest 1 GB. Haven't looked into why, might be some low-hanging fruit here.

wal_acceptor_throughput/fsync=false/size=1024
                        time:   [14.427 s 14.487 s 14.550 s]
                        thrpt:  [70.378 MiB/s 70.683 MiB/s 70.979 MiB/s]
wal_acceptor_throughput/fsync=false/size=4096
                        time:   [4.8211 s 4.8395 s 4.8602 s]
                        thrpt:  [210.69 MiB/s 211.59 MiB/s 212.40 MiB/s]
wal_acceptor_throughput/fsync=false/size=131072
                        time:   [1.9312 s 1.9410 s 1.9518 s]
                        thrpt:  [524.66 MiB/s 527.55 MiB/s 530.25 MiB/s]
wal_acceptor_throughput/fsync=false/size=1048576
                        time:   [1.9040 s 1.9095 s 1.9155 s]
                        thrpt:  [534.60 MiB/s 536.27 MiB/s 537.81 MiB/s]