4 ms·

One situation might be that you roughly know how much memory your process should be consuming and kill it if it's overconsuming. Something akin to but more dyna

• remram 3y ago
  That's probably something you would want to do as soon as the process is outside its limits, without waiting for a OOM situation.
  • mort96 3y ago
    Right, but you may not catch it before the OOM situation arises I guess?
  • dzaima 3y ago
    That could end up with significant false-positives when updating the thing without updating the estimated memory usage (especially if slow bounded fragmentation over a long period of time applies). You might also have some expected ratio of memory usage (e.g. process B uses 3x the memory of process A), but want to allow the absolute usage to grow as more data is processed.
    • remram 3y ago
      Having the wrong limits will cause the wrong thing to die, regardless of whether they kick in during OOM or orchestration. Better to find out during your planned rollout window if you ask me.
• omoikane 3y ago
  I always used `ulimit -v` and `ulimit -H -v` for this purpose. Maybe this is more fine grained?