Repository navigation
fix(installer): floor web-pdf at 1250MB (#2951) - #2956
Merged
Merged
Conversation
web-pdf drives headless Chrome to render PDFs. Chromium OOMs in printPage below ~1250MB. stack.go had web-pdf MinMemory at 1024, so on a 16GB host (the README minimum) the weighted BalanceMemory split assigned it only ~1128MB, below the working threshold. This is the same failure mode as #2934 (web-pdf OOM'd at ~1.1GiB). Raise MinMemory 1024 -> 1250. A 16GB host still fits all service minimums (total min 13,682MB < 15,384MB available after the 1GB OS reserve), and the weighted split then assigns web-pdf 1342MB there.
❌ Go dependencies check failedThere are outdated Go dependencies, or modules that could not be inspected. Script output |
🛑 AI review — Engineer review requiredThis PR touches critical paths or introduces changes the model cannot judge with sufficient confidence. @Kbayero @osmontero please review. 🛑
|
![utmstackprapprover[bot]](https://avatars.githubusercontent.com/u/144401876?s=60&v=4){kind=small}
5 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fix the one real defect in #2951: web-pdf memory floor
#2951 is mostly a design proposal (fixed profiles vs the weighted split), but it exposed one concrete defect in the current code:
web-pdfcan be sized below what headless Chrome needs.stack.gohadweb-pdf MinMemory: 1024. On a 16 GB host — the README minimum — the weightedBalanceMemorysplit assigned web-pdf only ~1,128 MB, below the ~1,250 MB threshold where Chromium OOMs inprintPage. This is the same failure mode as #2934, where web-pdf OOM'd at ~1.1 GiB on a large report.Change:
web-pdf MinMemory 1024 → 1250.Verification (simulated
BalanceMemoryverbatim):1128 → 1342 MB(now above the threshold); still fits all service minimums (total min 13,682 MB < 15,384 MB available after the 1 GB OS reserve).1349 → 1563 MB.go test ./...passes.Not included (per the #2951 comment): the profile table, per-size OpenSearch heap,
--invert, and recalc rollback. Those are design/feature changes with their own tradeoffs (the 16/32 GB profiles actually leave the OS less headroom than the current 1 GB reserve, and the 20 GB profile's OpenSearch is thin on off-heap), and I'd rather scope them separately once the approach is settled.Related: #2951, #2934, #2918