2 GB vs 10 GB: The Honest Result of My RAM Upgrade

My three-year-old daughter would press play in Kids Player and wait ten seconds for the sound to start. That wait is why I upgraded my NAS from 2 GB to 10 GB of RAM.

So: did it work?

The honest answer is two answers. On paper, the upgrade was a triumph. In daily life, it made things about one second better. Both are true, and the gap between them is the most useful thing I learned.

The proof: the numbers really did change

I took the same five measurements before and after the upgrade, at idle, using the same commands. Here is the before and after, side by side.

Available memory went from 530 MB to about 7 GB — roughly 13 times more headroom. The swap, which had been carrying 1 GB of pushed-out data, dropped to zero. The four zram compressed-swap partitions, which had been 88% full, emptied completely.

Before: 2 GB total, 58% used, 118 MB free. The gauge looked “fine.”

After: 10 GB total, 17% used, 5.7 GB free.

There was even a surprise in the container numbers. After the upgrade, some apps reported more memory than before — the Node.js app went from 1.9 MB to 72 MB, a Flask app from 0.5 MB to 50 MB. That is not the apps growing. That is the truth becoming visible. On 2 GB, the system had been compressing those apps’ memory into zram, so they only looked tiny. With room to breathe, they show their real size.

The story: did I jump the gun?

Here is the part I went back and forth on.

In the days right before I installed the RAM, the freeze had mostly stopped. Two days earlier my daughter waited ten seconds. But the day before the install, and the morning of it, Kids Player felt fine. The memory gauge read 58%, which looks like plenty of room.

So I had a real doubt: was this upgrade premature? Did I just spend ₩76,000 fixing a problem that had already gone quiet?

The data answered it, sort of. Before the upgrade, zram really was 88% full. The system was already leaning hard on compressed swap. The reason the freeze came and went is that zram only overflowed to the slow hard drive under load — the exact moment my daughter pressed play and the app needed memory right now. At idle, everything looked calm. The easy gauge gave a false sense of safety. The strain was real, it was just hidden until something needed memory in a hurry.

So no, the problem was not imaginary. But it also was not the constant emergency the dramatic numbers might suggest.

The how: what the upgrade actually fixed

After the upgrade, I timed Kids Player myself with a stopwatch.

• A cold open (first time after a while): about 5 seconds
• Opening it again right away: about 3 seconds
• The improvement I could feel versus before: about 1 to 1.5 seconds

That is not “ten seconds down to under one second.” It is honest, and it is smaller than I expected.

Here is what I think happened. The RAM upgrade removed the worst case — the random ten-second freezes when zram overflowed to disk under load. Those are gone. But the everyday three-to-five-second open time was never really a memory problem. The two seconds between a cold open (5s) and a warm one (3s) is disk and cache warming up. The three seconds that remain are the app itself starting: Node.js booting, the interface drawing, the media list loading. More RAM cannot shrink that floor. Only better code can.

Was it worth ₩76,000?

For me, yes — but not for the reason I expected.

It did not make the app feel twice as fast. What it bought me is the end of the random ten-second freezes, and a server with real headroom so I can keep adding apps without the next one tipping it over. The daily speed difference my daughter notices is about one second. The graphs scream success; her experience got quietly, slightly better. I am keeping the RAM, and I am telling you the plain truth so you can judge it for your own setup.

And the three-second floor that is left? That is not on my shopping list. It is on my to-do list. The next improvement to Kids Player will come from the code, not from hardware — which, honestly, is the part I enjoy more anyway.