Chart screenshot included here

Hello Charbs,

That looks like a memory leak, especially so since it is about to follow the same curve up.

Unfortunately, we have no visibility into what your code is doing or why it is using the memory it is, given we are simply running your app as-is and reporting on the memory it uses.

Though I've heard the Sharp package for image optimizations often causes massive memory bloat, are you perhaps using that?

From looking at the service's own metrics graph, it looks like this memory leak was introduced after you uploaded new code with railway up on Sept 17th.

Thanks Brody. I think I've fixed the line that was causing this... The graph looks a lot normal now but i'll keep observing.

Awsome, I'm glad to hear that, would you mind telling me what it was?

To be honest i'm now skeptical, given the graph shows a massive spike then a massive drop, due most likely to a new deployment. As soon as i deployed earlier today it also dropped, so i am expecting the graph and gradually go up in the next 6-12 hours.

But the line i did change was a simple check for the array before checking its length (`v-if="comments && comments.length"`)

This did indeed look like a memory leak. You'll want to have a look at your code to see if you can narrow it down

Thanks Jake. I've spent the last few days trying to pinpoint the issue to no avail - i really can't tell what it is. It also does not help that i'm not the most experienced in finding leaks, so i'm learning my way around the dev console memory tab in hopes of finding something obvious.

For now, are you able to help me with this: When i see the memory graph on railway, what exactly is that representing? What i mean is, is there a "single" instance of my website being served to all my visitors? Or is the memory consumption the culmination of many instances (equal to the amount of users on the site at a given time)?

Given that we are running your code as-is, and we aren't serverless, that means it's running a single process 24/7 and the graph is how much that process is using memory wise.

As previously mentioned these slow but steady rises in memory started after a railway up on September 17th, If you use git I would recommend reverting to a commit before then.

Thanks Brody. Believe it or not i still have not been able to pinpoint exactly what was causing that spike. The huge spike has been fixed but i still see the memory going up (albeit not as aggressively) until I deploy.

Is there anything you recommend i do to better understand the memory usage?

Maybe you can use Grafana to pinpoint exactly what part of app code / sources is using tons of memory