perf: cut build memory so the site builds on an 8 GB machine - #8052
Open
saurabhraghuvanshii wants to merge 1 commit into
Open
saurabhraghuvanshii wants to merge 1 commit into
saurabhraghuvanshii wants to merge 1 commit into
Conversation
|
Important Review skippedToo many files! This PR contains 262 files, which is 112 over the limit of 150. To get a review, reduce the PR to 150 files or fewer by splitting it into smaller PRs or changing its base branch. Upgrade to a paid plan to raise the limit. This review couldn't start because sufficient usage credits or metered capacity aren't available. Add credits or update usage-based reviews in the billing tab, then retry. ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: ⛔ Files ignored due to path filters (118)
📒 Files selected for processing (262)
You can disable this status message by setting the Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
github-actions
Bot
added
project/meshery
area/news
Contributor
|
Preview deployment for PR #8052 removed. This PR preview was automatically pruned because we keep only the 3 most recently updated previews on GitHub Pages to stay within deployment size limits. If needed, push a new commit to this PR to generate a fresh preview. |
`npm run build` needed ~13.4 GB peak (9.8 GB in a single process) and `gatsby develop --full` OOM-crashed outright. Profiling the webpack module graph, the sharp job queue and the per-stage memory timeline turned up four repository-specific causes. 1. The `@mui/icons-material` barrel dominated the module graph. Two pre-bundled dependencies (`@sistent/sistent`, `@sistent/mui-datatables`) import the whole barrel for 17 icons, and webpack resolved and parsed all ~10,800 icon modules in both the browser and the SSR compilation: 10,819 of 18,949 modules. `gatsby-node.js` now aliases the exact specifier to a generated shim that deep-imports only the icons those bundles use, taking the graph to 8,211 modules (-57%). Deep imports are untouched. `npm run generate:mui-icon-shim` regenerates the list by scanning node_modules, so it is derived rather than guessed. 2. Source images were far larger than anything the site renders. 673 images exceeded 1600px (one PNG was 18534x5417) against a maximum rendered width of 1920px, and sharp's cost scales with source megapixels. Capping the long edge at 2000px (1200px for member photos, rendered at 500px) across 362 files cuts total source megapixels 4,603 -> 2,400 (-48%) and 60 MB of repository size, with no change to any rendered size. 3. `gatsby-plugin-purgecss` did nothing. Its own log reported "Removed ~0.00 KB" every build, because `purgeOnly: ["src/"]` matches no CSS the site actually imports. Removed; CSS output is byte-identical. 4. `@mui/material` was in the shared bundle of all 1,348 pages, because `CookieConsent` (rendered from `layout.js`) imported it for a Snackbar. Rebuilt on styled-components, the site's own styling system. Also: `gatsby-plugin-preload-fonts` was declared but never registered as a plugin, pulling puppeteer and a Chromium download into every `make setup` (-400 MB of node_modules); `scripts/run-gatsby.js` now derives Gatsby's worker count, sharp concurrency and V8 heap ceiling from the RAM the machine actually has (honouring cgroup limits, so it is correct under WSL2 and in containers) instead of hardcoding 8 GB; and 16 unreferenced assets that were byte-identical duplicates of files still in use were deleted. Measured on the same machine, full production build: peak memory 13,445 MB -> 9,959 MB (-26%) peak process 9,845 MB -> 8,319 MB (-15%) build time 535s -> 416s (-22%) webpack modules 18,949 -> 8,211 (-57%) app.js 7,784 KB -> 2,259 KB (-71%) total JS 38.8 MB -> 32.3 MB (-17%) .cache 2.1 GB -> 1.7 GB pages built 1,348 -> 1,348 (unchanged) Under a hard 8 GB cgroup limit `npm run build` now completes (peak 8,914 MB) where it previously died with "Ineffective mark-compacts near heap limit". `make site` peaks at 5,405 MB and is serving in 169s under a 6 GB limit, and `make site-full` now reaches a usable dev server instead of OOM-crashing.
saurabhraghuvanshii
force-pushed
the
perf/reduce-build-memory
branch
from
September 13, 2026 22:08
845ff22 to
4606840
Compare
dhruveshmishra
left a comment
dhruveshmishra
left a comment
Contributor
There was a problem hiding this comment.
src/assets/images/careers/Lee-giving-away-free-t-shirts-at-UT-Austin.jpeg
The image added in this files seems to be reversed
This comment was marked as duplicate.
This comment was marked as duplicate.
Sorry, something went wrong.
dhruveshmishra
left a comment
dhruveshmishra
left a comment
Contributor
There was a problem hiding this comment.
src/assets/images/Community-pictures/D IMG_6521.jpeg
src/assets/images/Community-pictures/F IMG_6936.jpeg
These images are also seem to be tilted
Maanvi212006
left a comment
Maanvi212006
left a comment
Contributor
There was a problem hiding this comment.
same as @dhruveshmishra mentioned these images are inverted. Rest all look correct!
- src/assets/images/Community-pictures/D IMG_6521.jpeg
- src/assets/images/Community-pictures/F IMG_6936.jpeg
- src/assets/images/careers/Lee-giving-away-free-t-shirts-at-UT-Austin.jpeg
dhruveshmishra
left a comment
dhruveshmishra
left a comment
Contributor
There was a problem hiding this comment.
Many svgs are seems to be posted duplicately ,is it intentional or what
Like:-
src/assets/images/learning-path/istio/Prometheus.webp
src/assets/images/learning-path/istio/jaeger_1.webp
vedant21-ctr
suggested changes
Sep 16, 2026
vedant21-ctr
left a comment
vedant21-ctr
left a comment
Contributor
There was a problem hiding this comment.
A few things to address:
Image orientation: Lee-giving-away-free-t-shirts-at-UT-Austin.jpeg, IMG_6521.jpeg, and IMG_6936.jpeg are visibly rotated/mirrored compared with the originals. Please investigate why the resize step is altering orientation. EXIF handling is one possible cause worth checking.
Since 362 images were resized, please validate the full set against the originals, rather than only fixing these 3, to ensure there are no other image regressions.
With 262 changed files and CodeRabbit skipping the review due to the file-count limit, consider splitting the image changes from the build/webpack changes. Not a blocker, but it would make both parts easier to review.
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
5 participants
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.
npm run buildneeded ~13.4 GB peak (9.8 GB in a single process) andgatsby develop --fullOOM-crashed outright. Profiling the webpack module graph, the sharp job queue and the per-stage memory timeline turned up four repository-specific causes.The
@mui/icons-materialbarrel dominated the module graph. Two pre-bundled dependencies (@sistent/sistent,@sistent/mui-datatables) import the whole barrel for 17 icons, and webpack resolved and parsed all ~10,800 icon modules in both the browser and the SSR compilation: 10,819 of 18,949 modules.gatsby-node.jsnow aliases the exact specifier to a generated shim that deep-imports only the icons those bundles use, taking the graph to 8,211 modules (-57%). Deep imports are untouched.npm run generate:mui-icon-shimregenerates the list by scanning node_modules, so it is derived rather than guessed.Source images were far larger than anything the site renders. 673 images exceeded 1600px (one PNG was 18534x5417) against a maximum rendered width of 1920px, and sharp's cost scales with source megapixels. Capping the long edge at 2000px (1200px for member photos, rendered at 500px) across 362 files cuts total source megapixels 4,603 -> 2,400 (-48%) and 60 MB of repository size, with no change to any rendered size.
gatsby-plugin-purgecssdid nothing. Its own log reported "Removed ~0.00 KB" every build, becausepurgeOnly: ["src/"]matches no CSS the site actually imports. Removed; CSS output is byte-identical.@mui/materialwas in the shared bundle of all 1,348 pages, becauseCookieConsent(rendered fromlayout.js) imported it for a Snackbar. Rebuilt on styled-components, the site's own styling system.Also:
gatsby-plugin-preload-fontswas declared but never registered as a plugin, pulling puppeteer and a Chromium download into everymake setup(-400 MB of node_modules);scripts/run-gatsby.jsnow derives Gatsby's worker count, sharp concurrency and V8 heap ceiling from the RAM the machine actually has (honouring cgroup limits, so it is correct under WSL2 and in containers) instead of hardcoding 8 GB; and 16 unreferenced assets that were byte-identical duplicates of files still in use were deleted.Measured on the same machine, full production build:
peak memory 13,445 MB -> 9,959 MB (-26%)
peak process 9,845 MB -> 8,319 MB (-15%)
build time 535s -> 416s (-22%)
webpack modules 18,949 -> 8,211 (-57%)
app.js 7,784 KB -> 2,259 KB (-71%)
total JS 38.8 MB -> 32.3 MB (-17%)
.cache 2.1 GB -> 1.7 GB
pages built 1,348 -> 1,348 (unchanged)
Under a hard 8 GB cgroup limit
npm run buildnow completes (peak 8,914 MB) where it previously died with "Ineffective mark-compacts near heap limit".make sitepeaks at 5,405 MB and is serving in 169s under a 6 GB limit, andmake site-fullnow reaches a usable dev server instead of OOM-crashing.Description
This PR fixes #
Notes for Reviewers
Signed commits