Skip to content

perf(exporter): retain pre-compressed deflate payloads in memory - #6059

Merged
another-rex merged 2 commits into
google:masterfrom
another-rex:investigate_exporter_performance_discrepancy
Sep 24, 2026
Merged

another-rex merged 2 commits into
google:masterfrom
another-rex:investigate_exporter_performance_discrepancy

Conversation

@another-rex

@another-rex another-rex commented Sep 23, 2026

Copy link
Copy Markdown
Contributor

I give up on saving memory by writing to disk.

Previously, the exporter staged ~2M pre-compressed .deflate files to the local scratch disk in Phase 1, then re-opened and streamed them into ZIP archives during Phase 2. On ext4 filesystems with millions of entries in a single directory, this caused a lot of stall time and contention. (up to 87.6% stall time in test), causing the exporter to overrun the 15 minutes.

The guess for why this is only happening in test currently is because of how long the node has been live for, keeping all those files on disk, increasing the disk pressure.

Because all 2M compressed payloads only consume ~8.5 GiB in total (well within the 50 GiB GOMEMLIMIT and 60 GiB memory limit), we now retain the pre-compressed bytes directly in memory on vulnMeta.

Also changes -cleanup-scratch-dir default to true now that the scratch directory only holds ~47 temporary .zip files (<1ms deletion).

agy

Stage pre-compressed deflate payloads in memory on vulnMeta instead of writing 2M+ small files to local scratch disk. Eliminates ext4 directory inode lock contention and 4M+ file syscalls during ZIP creation.

Also updates -cleanup-scratch-dir to default to true.
michaelkedar
michaelkedar previously approved these changes Sep 23, 2026
Comment thread go/cmd/exporter/downloader.go Outdated
Comment on lines +83 to +82
compressedBytes := compBuf.Bytes()
compressedBytes := bytes.Clone(compBuf.Bytes())

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the clone here actually necessary?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not really, I guess it resizes the buffer down to the right size so we don't have the extra room taken up. But probably not a big deal.

compBuf is scoped to each loop iteration and never mutated. Using compBuf.Bytes() directly avoids 2M heap allocations and memmoves during download.
@another-rex
another-rex merged commit 51c2062 into google:master Sep 24, 2026
24 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