The Curious Case of Beam CPU Usage (2019)

The Curious Case of Beam CPU Usage (2019)(stressgrid.com)

36 points by fzil 1 year ago | 6 comments

I'm surprised they didn't measure the tail latency, that's where I'd expect busy waiting to make a difference

fzil 1 year ago |

been reading / work with elixir and was interested in finding out the cause of high cpu usage.

TLDR: BEAM VM uses busy waiting under the hood to achieve fast response time when dealing with requests. you can disable it by setting a few options in the VM.

Edit: Interesting thing here is that there's no significant latency difference when toggling busy/wait, so not sure why that's the default.

juped 1 year ago | |

It's because their test is bad at testing this behavior, this behavior is useful for a "bursty" traffic pattern. The point is to keep the OS scheduler from expensively context switching out of BEAM when it's idle, requiring an expensive context switch back when a new burst of requests comes in. You'd want to send it a heavy burst of 1000 requests at random delays, or something.

The only time you'd want to disable it is if you're under a CPU quota, or if you have some other important OS process that's not getting enough CPU.

01HNNWZ0MV43FF 1 year ago | |

That's strange. I understand busy waiting for up to some milliseconds so you don't yield too soon, but if it busy waits all the time by default it's just a bad neighbor.

All that said... A while back, inspired by an argument here on HN, I tested waking up a program 100 times per second and I was shocked that it didn't really show up in CPU usage nor power usage. Maybe an easier way to get started with async code, since you don't have to mess with wakers

paradox460 1 year ago | | |

When coming from telephony and high availability, you don't put neighbors in the same hardware. This is BEAMs way of overcoming shortcomings in the CPU and OS schedulers. And you can turn it off with a simple configuration