What are the patterns around dealing with busy processes?

Hi I’m completely new to Elixir and Erlang. I was reading the documentation at https://elixir-lang.org/getting-started/introduction.html and was wondering about some details around processes which is the most interesting feature of Elixir (to me).

What are the patterns around dealing with busy processes? If calls to send can never block how can a sender detect if a process is busy? Is there a way to rate limit sender? What happens if the receiver never calls receive does memory just fill up?

Thanks

1 Like

Generally you can’t or don’t. You use other mechanisms to handle overload([2]).

Yes. The mailbox of the process fills up and eventually you run out of memory.

Two links which explains a bit about erlang/elixir scheduling and how to handle overload of unbounded mailboxes.

[1] http://jlouisramblings.blogspot.com/2013/01/how-erlang-does-scheduling.html
[2] https://ferd.ca/handling-overload.html

3 Likes

Typically a process that is expected to receive heavy messages does not perform any work, instead it would spawn Tasks to handle each as it comes in. The current default limit for processes is 262144, and this is configurable. Use processes.

You would limit rates if and only if you are trying to access some critical resource, in which case put a buffer (bit-bucket / queue) in between. Usually this means using ets or mnesia or RabbitMQ as a holding area for messages.

what problem are you solving?

usually you would use a genserver - and the call would have timeout 5 secs by default…

also look at GenStage for back pressure/rate limiting etc…

but all depends on the actual problem that is being solved…

Plus if a process’s mailbox is pretty full then it ‘slows’ down sending to it more and more the more full it is, so a process sending a message to it will be ‘back-pressured’. This doesn’t help if it’s a new process sending a new message every time but it helps throttle the system under most loads.

But ‘OTP’ is the main pattern used to manage processes, and there is a lot built up on it. :slight_smile:

It’s also important to note that:

  1. Even if this (e.g. a process in an infinite loop) happens, it will not immediately bring down your system, because of the pre-emptive scheduling of the BEAM VM.

  2. You can easily see that a process is broken by using tools such as :observer whenever you are awake and looking at your system again, then figure out what is going on, fix it and hot-upgrade the system without causing any downtime.

I can really recommend the talk Solid Ground by Sasa Juric, where he gives more info, and live creates, introspects and fixes a ‘broken’ process!

1 Like

Thanks for all the replies. You have given me much to think about.

Not anymore, I think. It’s been removed in either v20 or v21.

Some more (quite enlightening) discussion about it.

4 Likes

Interesting! I did not know about that! Thanks! :slight_smile: