Skip to content

PXB-3543 [8.4] : Xtrabackup is extremely slow when performing incremenal backup for 1 Million Tables - #1722

Merged
satya-bodapati merged 2 commits into
percona:8.4from
satya-bodapati:8.4
Jan 19, 2026
Merged

PXB-3543 [8.4] : Xtrabackup is extremely slow when performing incremenal backup for 1 Million Tables#1722
satya-bodapati merged 2 commits into
percona:8.4from
satya-bodapati:8.4

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.
@satya-bodapati

Copy link
Copy Markdown
Contributor Author

trunk: #1723

@satya-bodapati
satya-bodapati merged commit ea3ad50 into percona:8.4 Jan 19, 2026
3 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.

2 participants