Memory usage still climbing pretty steadily, we're at ~450MB now.
-
Memory usage still climbing pretty steadily, we're at ~450MB now. Most of it seems to be from postgres going my the MEM% sorting. My guess is it's the cached media from browsing on the TL.
RE: https://mt.watamelon.win/objects/019191d9-d724-c51d-ba8f-20df4ff5fee7
-
Good news it has stabilized there. Kind of wondering if it'll reach 1GB again.
-
Nevermind we have reached 500MB
-
690 now, majority Postgres
-
716MB now, here's the details
-
@tadano No idea what's going on here. Mitra process looks good (~60M?)
On my machine postgres never consumes more than 200M (it is usually at ~150M), though that might be due to that machine having only 512M memory in total. I also set
shared_buffers
to 32M in postgres configI recommend executing
mitractl instance-report
, maybe it will show something interesting. -
@tadano cached media is stored in a filesystem, it doesn't affect database performance
-
@silverpill Good morning! Here's what
mitractl instance-report
spits out. Also as of now 925MB of RAM is being used, almost all of it being postgres processes.Edit: Added the htop screen
-
@silverpill also mad respect for running your instance on only 512MB of RAM. What distro are you using?
-
@tadano Everything looks normal. Have you looked at postgres log? Usually it can be found in /var/log/postgresql/
Maybe it's just postgres optimizing for performance by aggressively caching stuff in memory.
-
@tadano Debian :3
-
@silverpill Didn't find too much so far save for a ton of
duplicate key value violates unique constraint
errors. The strings related in grep were the most common occurrences. I don't know if that's specifically related to it, anything off the top of your head I should be looking for in regards to postgres aggresively caching?Also slightly unrelated, but according to PGTune I should be serring my
shared_buffers
to 4GB lmao -
>Didn't find too much so far save for a ton of duplicate key value violates unique constraint errors.
Unique constraint violations are normal, the are handled at the application level.
>I don't know if that's specifically related to it, anything off the top of your head I should be looking for in regards to postgres aggresively caching?
Even at 1G it is still < 10% of what you have, and so far there is no sign of any problem. I'd leave it as is.
I can't tell you much about pg fine tuning, for that it would be better to consult with documentation https://www.postgresql.org/docs/current/runtime-config-resource.html