morningman opened a new pull request, #4030:
URL: https://github.com/apache/doris-website/pull/4030

   ## What & Why
   
   The `Cron Deploy` and `Manual Deploy And Upload To OSS` jobs have been 
failing intermittently for the past several days (e.g. 
[30743875275](https://github.com/apache/doris-website/actions/runs/30743875275),
 
[30751563874](https://github.com/apache/doris-website/actions/runs/30751563874)),
 and went into a consecutive-failure streak on Aug 2.
   
   Diagnosis from the run logs:
   
   - Every failure ends with `##[error]The runner has received a shutdown 
signal` in the middle of the Build step — the runner VM itself is killed, not a 
build error and not a workflow timeout.
   - The same commit (`3862366c`) both passed and failed repeatedly across Aug 
1–2, and the runner image version is identical between passing and failing runs 
(ubuntu-24.04 / 20260720.247.2), ruling out code or image changes.
   - Failures consistently happen during the memory-heaviest phase (en static 
generation finished, zh-CN webpack build in progress), after several minutes of 
log silence, and with no `JavaScript heap out of memory` error — the classic 
signature of system-level memory exhaustion killing the runner service: the 
main node process is allowed `--max-old-space-size=8192` and the webpack/terser 
worker processes push the total past the standard runner's 16G physical memory.
   
   ## Fix
   
   Add an extra 8G swapfile before the Build step in both deploy workflows, so 
memory spikes spill into swap instead of getting the VM OOM-killed:
   
   - The swapfile is placed on the `/mnt` data disk (~65G free) instead of the 
root disk, which the workspace and build output already fill; named `swapfile2` 
because the runner image ships a built-in 4G `/mnt/swapfile` — total 12G swap 
after this change.
   - `free -h` / `swapon --show` output is printed so future failures can be 
triaged against the memory baseline directly from the logs.
   
   This is a mitigation for the flaky OOM kills. A follow-up improvement worth 
considering is splitting `docusaurus build --locale en --locale zh-CN` into two 
separate invocations so each locale's peak memory is isolated in its own 
process.
   
   🤖 Generated with [Claude Code](https://claude.com/claude-code)


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to