Context: web server hosted on DigitalOcean with a PostgreSQL database.
We were experiencing recurring database crashes for unknown reasons. Eventually I nailed down a faulty query that was overloading the system and am almost sure that's the issue.
However as I was investigating postgres crashes, I came across a post mentioning tweaking the system's kernel.shmmax because it's related to the postgres setting shared_buffer.
Turns out when I run cat /proc/sys/kernel/shmmax its value is 18446744073692774399! I've no idea why, but this seems crazy.
Anyway, why might this value be so large and what should it be?
Memory usage in our droplet (total 16 GB) used to be around 87%. After my query fix when the server restarted it stayed lower at about 47% and over time got back to about 84% after a few hours. There is no sysadmin but I assumed to think the high value of sshmax might be involved?
Other relevant postgres settings are:
shared_buffers = 4GB
max_connections = 300
max_wal_size = 2GB
checkpoint_timeout = 15min
checkpoint_timeout = 15min
checkpoint_completion_target = 0.9
My question is about the high shmmax value and how it might be related to faulty postgres settings and why memory usage goes up like that.
