You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/docs/how-to/performance/resolving-out-of-memory-issues.md
+5-5
Original file line number
Diff line number
Diff line change
@@ -62,7 +62,7 @@ Paid tiers of Gatsby Cloud parallelize image processing and run other parts of t
62
62
63
63
Gatsby defaults to using the number of physical cores on your machine to speed up builds, and parallelizes during certain steps of the process (image processing, Javascript bundle creation, and HTML generation).
64
64
65
-
So if you're experiencing out of memory issues during any of those steps, you can try setting the environment variable GATSBY_CPU_COUNT to a lower number, like 2. Note that this will slow your builds down!
65
+
So if you're experiencing out of memory issues during any of those steps, you can try setting the environment variable `GATSBY_CPU_COUNT` to a lower number, like 2. Note that this will slow your builds down!
66
66
67
67
#### Increase allocated memory and/or upgrade your hardware.
68
68
@@ -88,7 +88,7 @@ Finally, you can't allocate more memory than is available on your machine, so be
88
88
89
89
#### Pre-optimize images by downsampling
90
90
91
-
Overly large images being used by Gatsby image can cause memory spikes. For example, if your image will only ever be 1000 pixels wide, and you're have a 2000 x 3000 pixel source image stored in your repository or headless CMS, it may be worthwhile to convert that source image to a 667 x 1000 pixel version. [This piece on pre-optimizing images](https://www.gatsbyjs.com/docs/preoptimizing-images/) can give some guidance.
91
+
Overly large images being used by Gatsby image can cause memory spikes. For example, if your image will only ever be 1000 pixels wide, and you're have a 2000 x 3000 pixel source image stored in your repository or headless CMS, it may be worthwhile to convert that source image to a 667 x 1000 pixel version. [This piece on pre-optimizing images](/docs/preoptimizing-images/) can give some guidance.
92
92
93
93
#### Disable AVIF
94
94
@@ -98,13 +98,13 @@ Generating AVIFs often causes increased memory usage by gatsby-plugin-image. Thi
98
98
99
99
#### Turn off source maps generation
100
100
101
-
Use Gatsby plugin that disables sourcemap generation by modifying webpack config: [gatsby-plugin-no-sourcemaps](https://www.gatsbyjs.com/plugins/gatsby-plugin-no-sourcemaps/) (this can help build speed as well).
101
+
Use Gatsby plugin that disables sourcemap generation by modifying webpack config: [gatsby-plugin-no-sourcemaps](/plugins/gatsby-plugin-no-sourcemaps/) (this can help build speed as well).
102
102
103
103
The side effect is that this will make any errors happening in production significantly harder to debug by obscuring the stacktrace, so if your team regularly inspects production errors (perhaps using eg Sentry, Rollbar, or comparable tools), you may want to consider other options.
104
104
105
105
#### Inspect and reduce bundle sizes
106
106
107
-
Serialization memory spikes are proportional to template sizes. [Optimizations to improve bundle size](https://www.gatsbyjs.com/docs/how-to/performance/improving-site-performance/#reduce-your-javascript-bundle-cost), especially of your largest bundle sizes, should have benefits to this.
107
+
Serialization memory spikes are proportional to template sizes. [Optimizations to improve bundle size](/docs/how-to/performance/improving-site-performance/#reduce-your-javascript-bundle-cost), especially of your largest bundle sizes, should have benefits to this.
108
108
109
109
When you're scanning bundle sizes to see what might be causing out-of-memory issues, rather than focusing on critical paths, focus on anomalously large bundles. If one of your bundles is 3MB and the rest are 300KB, you might have, eg, accidentally imported an 2.5MB image directly into a bundle.
110
110
@@ -126,6 +126,6 @@ Because the amount of baseline memory usage is roughly proportional to the numbe
126
126
127
127
#### Disable cache persistence
128
128
129
-
When the amount of nodes approaches 1.5 million (typically a 100k page Contentful site, or a 300k page Sanity site), the way Gatsby serializes internal state can cause out of memory issues. If your site is near this, and you're experiencing issues, try setting the environment variable GATSBY_DISABLE_CACHE_PERSISTENCE=1.
129
+
When the amount of nodes approaches 1.5 million (typically a 100k page Contentful site, or a 300k page Sanity site), the way Gatsby serializes internal state can cause out of memory issues. If your site is near this, and you're experiencing issues, try setting the environment variable `GATSBY_DISABLE_CACHE_PERSISTENCE=1`.
130
130
131
131
Note that for sites at this scale, build times may also become a workflow issue for your team, so be sure to spend time thinking about how to improve build times as well.
0 commit comments