Skip to content

Merge fix for PXB-3543 from 8.0 to release-8.0.35-35 - #1724

Merged
satya-bodapati merged 2 commits into
release-8.0.35-35from
8.0
Jan 19, 2026
Merged

Merge fix for PXB-3543 from 8.0 to release-8.0.35-35#1724
satya-bodapati merged 2 commits into
release-8.0.35-35from
8.0

Conversation

@satya-bodapati

Copy link
Copy Markdown
Contributor

No description provided.

…al backup for 1 Million tables https://perconadev.atlassian.net/browse/PXB-3543

Optimize incremental backup buffer initialization

**Problem:**
Incremental backups were suffering from extremely high CPU usage (up to 82%
in perf reports) attributed to `__memset_avx512_unaligned_erms`.
The root cause was the initialization of the delta buffer (~67MB per thread).
The kernel lazily allocates physical RAM, so the initial `memset` triggered
millions of Page Faults (`asm_exc_page_fault`), forcing the kernel to pause
execution, allocate RAM, and zero it out. Additionally, flushing the buffer
involved a redundant `memset` that wasted memory bandwidth.

**Solution:**
1. Removed the full-buffer `memset` in `wf_incremental_init`.
2. Removed the full-buffer `memset` in `wf_incremental_process` (flush loop).
3. Replaced both with a "surgical" `memset` that only zeroes the first page
   (the Index Page).

**Safety Analysis:**
The delta buffer consists of Page 0 (Index/Header) and Pages 1..N (Data).
- **Page 0:** Must be zeroed to ensure the file headers are clean and no
  garbage data exists after the `0xFFFFFFFF` sentinel. The new `memset`
  handles this.
- **Pages 1..N:** These are populated sequentially via `memcpy`. We track
  the number of valid pages (`npages`) and only write `npages * page_size`
  to disk. Any "dirty" or uninitialized memory at the tail of the buffer
  is never read and never written to the file.

**Impact:**
- Eliminates the "First Touch" page fault storm during initialization.
- Saves ~67MB of memory write bandwidth per flush cycle per thread.
- Drastically reduces system CPU time during incremental backups.
PXB-3543 [8.0] : Xtrabackup 8.0 is extremely slow when performing incremenal backup for 1 Million Tables
@satya-bodapati satya-bodapati self-assigned this Jan 19, 2026
@satya-bodapati
satya-bodapati merged commit be44763 into release-8.0.35-35 Jan 19, 2026
5 checks passed
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