Hacker News Reader

Comment by dguaraglia | Hacker News Reader

Not trying to be flippant, but by extending your analogy: if the Kubernetes supervisor dies (which is conceivable, no technology is infallible), then you are in the same scenario as something bringing your whole Elixir VM down. You can always run your Elixir VM using something like supervisord if you need another watchdog.

BTW, it's very hard to bring BEAM down. Most exceptions will bring kill the faulty process, but leave the supervisor tree untouched. Only "unmanaged" code (for example, calling a C library using a NIF) might crash the whole VM.

Then again, no technology is infallible.

View on HN

> You can always run your Elixir VM using something like supervisord if you need another watchdog.

Sounds like heart: http://erlang.org/doc/man/heart.html

>BTW, it's very hard to bring BEAM down. Most exceptions will bring kill the faulty process, but leave the supervisor tree untouched. Only "unmanaged" code (for example, calling a C library using a NIF) might crash the whole VM.

Not completely true. Try to allocate more memory than available and then see what happens.

I'm actually curious. Do you have some first-hand experience with that kind of issue? I've only played around with Elixir and my only experience deploying BEAM-based applications on production has been RabbitMQ and CouchDB and both of those were very solid.

Also, isn't ENOMEM a standard error that you can handle using the standard error handling techniques?

I have and it wasn't good. It is impossible to handle out of memory exceptions inside the BEAM. At best, you can hope for a crash of the VM. At worse, it just hangs. And one will most likely not find out about this until they hit this scenario.

Interesting, definitely worth knowing beforehand (I was thinking of implementing a small service that could be pretty memory-intensive using Elixir.) I wonder if there's a way to try and manage memory to avoid ENOMEM.

If BEAM is allocating memory it must either be copying a message from one process to another, allocating space in a process for its stack, or for some bookkeeping like to spawn a new process. In the first two cases why doesn't it just kill the process and send the usual link and monitor messages to let other Erlang processes handle the failure?

How would it send a message if it can't allocate memory anymore?

Haha, yeah, that's the problem with ENOMEM handling in general: unless you have a very clear path to free memory immediately and then try to do some reasonable cleanup, you are screwed. Back in the bad old days of running Windows machines with 8mb of memory, I'd religiously handle that kind of error code... but I can't recall the last time I actually bothered. Commoditized hardware makes us lazy.

yeah I have to make liberal use of :hibernate to avoid just this.

True true, maybe there's just a single part that I was hung up on in parent comment

> (a process within the VM can die and K8s will have no idea)

I suppose that I see nothing wrong with this and would say that it's not weird or unusual to be the case. They're separate things, although they both achieve visually similar goals (keep things running as much as possible).

My point is less about K8s vs Elixir but rather a statement that this seems acceptable and shouldn't be a reason to rule out something like running Elixir on K8s.

Reply on news.ycombinator.com