To be clear, the above does not mean your server is running out of memory. It just means Erlang tooling for measuring memory/cpu usage has terminated, which will always be logged when Erlang shuts down.

So, without further evidence, all we know is that Erlang is shutting down. Do your logs say something else? Do you have metrics that say something else?

If it is a phoenix app, you can enable Phoenix.LiveDashboard, which may be easier to setup than observer: Phoenix.LiveDashboard — LiveDashboard v0.8.7

Open up the dashboard and you will be able to see if memory is growing, processes used, etc.

OOM errors are hard to debug. :observer and LiveDashboard may help, However, when **** happens, it usually happen quick enough that you don’t get the chance to observe clearly.

I can only offer a few high memory pitfalls that I have seen:

• Do you have process that do lot of work then idle for a long time? It may cause global binary not GC’ed soon enough. You can try to make those processes short-lived, or hibernate them.
• Do you read and parse largish files? You may try to use :raw mode to open files and tune the read_ahead size.
• Do you make a lot of sub-strings and keep them around for a long time? A sub binary will keep the original large binary from GC’ed. You can try to :binary.copy/1 them.

Optimizing ram usage is usually not worth the effort, this is a compromise GC languages have.

There is one thing when ram usage spikes happen and another when there is memory leaking, and judging by your description, you most probably have a spike.

For the record, what are the specs of your machine?