Linux

9612 readers

273 users here now

A community for everything relating to the GNU/Linux operating system (except the memes!)

Also, check out:

Original icon base courtesy of lewing@isc.tamu.edu and The GIMP

founded 2 years ago

MODERATORS

Ategon@programming.dev

anzo@programming.dev

dwraf_of_ignorance@programming.dev

Does zram impede disk cache? (swg-empire.de)

submitted 2 weeks ago* (last edited 2 weeks ago) by bjoern_tantau@swg-empire.de to c/linux@programming.dev

14 comments fedilink hide all child comments

In my relentless pursuit of trying to coax more performance out of my Lemmy instance I read that PostgreSQL heavily relies on the OSs disk cache for read performance. I've got 16 GB of RAM and two hdds in RAID 1. I've PostgreSQL configured to use 12 GB of RAM and I've zram swap set up with 8 GB.

But according to htop PostgreSQL is using only about 4 GB. My swap gets hardly touched. And read performance is awful. Opening my profile regularly times out. Only when it's worked once does it load quickly until I don't touch it again for half an hour or so.

Now, my theory is that the zram actually takes available RAM away from the disk cache, thus slowing the whole system down. My googling couldn't bring me the answer because it only showed me how to set up zram in the first place.

Does anyone know if my theory is correct?

you are viewing a single comment's thread
view the rest of the comments

[–] bjoern_tantau@swg-empire.de 1 points 2 weeks ago (1 children)

I definitely have disk io issues. I really wish I had an SSD or two.

[–] chirping@infosec.pub 2 points 2 weeks ago

If you are on HDD then looking at what else is using the same disk, and reducing that usage, may yield some results. Forexample, if /var/log is on the same disk and can't be avoided, then reducing log volume or batching writes may reduce the "context switches" your HDD has to do. There should be options for I/O limits/throttling/priority in systemd. If you have only postgres on the HDD, I'd consider giving it 90% of the max bandwidth -- maybe that'd be more effective than going full throttle and hitting the wall. If you have postgres and some other service fighting for the HDD's time, these limits could help. Make sure access time tracking is off (or set to relatime).