Kill the app at high RAM, instead of trying to throttle it first
Well, sitting at the `MemoryHigh` limit still grinds the app to a halt anyway, lmao. I guess it's a feature designed for well-behaved processes and not for outright leaking ones? Let's try just having systemd basically reset the app regularly when the RAM hits a certain threshold. I think that's what this config will do, we'll find out!
This commit is contained in:
parent
af705f1be0
commit
91eb2f7752
1 changed files with 7 additions and 2 deletions
|
@ -11,8 +11,13 @@ Environment="RAILS_ENV=production"
|
|||
Environment="EXECJS_RUNTIME=Disabled"
|
||||
EnvironmentFile=/srv/impress/shared/production.env
|
||||
|
||||
; Try not to go over 1GB of RAM, and kill the app at 1.2GB.
|
||||
MemoryHigh=1G
|
||||
; Kill the app at 1.2GB of RAM.
|
||||
; NOTE: It's generally recommended to pair this with a `MemoryHigh` setting, to
|
||||
; try throttling memory usage before killing altogether. But at time of writing,
|
||||
; our app has a memory leak that causes it to always keep growing - and then the
|
||||
; throttling *successfully* keeps it within the RAM limits, just running very
|
||||
; slowly. Instead, let's always reboot it when it gets too high, and hopefully
|
||||
; find and fix that leak sometime!
|
||||
MemoryMax=1.2G
|
||||
|
||||
; Some security directives, adapted from Akkoma's service file, they seem like sensible defaults!
|
||||
|
|
Loading…
Reference in a new issue