I thought maybe cap is on 500 images hence I have deleted some things but still it always stays on 0 %.
One more maybe really important thing is that yeah this smells like memory issue since on my local I had issues before due to low RAM, however I got another 8 GB and solved the issue, because I was getting same error of glib critical.
What is odd in this scenario is that same images I could deploy before on Netlify (which we can see from log provided) and when I did regular build its like its clogged, did Netlify change it’s infrastructure recently, maybe on free tier etc, like anything, since I really haven’t touched code or w/e.
Hello and thanks for chimming in here.
Well what is odd and already mentioned is that i have deducted even more images, and that my changes were kinda text only when it malfunctioned.
I saw that Netlify changed from Xenial to Focal so maybe that had some connections, but i can even show you in commits history, that there was nothing to cause that spike of ram usage.
Maybe some differente package cause this because it was not fixed or anything like that.
For the time being since its working on my local PC i have created dist repo where i store built files and serve them on Netlify through that however I am ofc not happy with solution but since i have 11k visitors per month and am reliant on updates on website it was the only way.
I dont think there is anything more that i can do to test this, Im affraid i found limitation in Netlify mostly because gridsome is kinda deprecated and that was first bad choice.
Maybe i will have to check how cloudflare pages are serving me, if their machines are stronger in future.
Netlify didn’t (yet) “change” from Xenial to Focal - you will need to change on your own; we didn’t enforce any change yet, so unless you changed (and if you did, you can change back on your own :)) that upcoming change is not the cause of anything today.
So I would suggest that next debugging steps are probably the same thing Hrishikesh said - next debugging steps are probably doing some profiling in our docker image. This is how to run it:
It’s my expectation that you’ll find that some version of your dependencies uses much more memory than an earlier version, once you start trying older ones. You can then lock a version in package.json or yarn.lock as mentioned here: Manage build dependencies | Netlify Docs
Perhaps you should also try it without the gridsome cache plugin? That is indeed quite old - not maintained in 2 years as far as I can tell: netlify-plugin-gridsome-cache - npm - but also probably not required to build your site?
To be honest this is too big of a exploration for small gain even if there is at end of tunnel, in the end if I consume too much RAM, there is nothing that can be done about it.
I will continue my workaround like i have mentioned:
Build on my local machine
version dist file
push to github and publish on netlify from that repo
Maybe in future i will rebuild this with Astro or some other framework since i think this is the Gridsome limitation which is kinda dead.
If you want make this solved thread since i wont take any further steps.