The Curious Case of Beam CPU Usage (2019)
stressgrid.com
The Curious Case of Beam CPU Usage (2019)
1–8 of 8 posts
Re: The Curious Case of Beam CPU Usage (2019)
#2been 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.
Re: The Curious Case of Beam CPU Usage (2019)
#3been 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.
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.
Re: The Curious Case of Beam CPU Usage (2019)
#4been 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.
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
Re: The Curious Case of Beam CPU Usage (2019)
#5I'm surprised they didn't measure the tail latency, that's where I'd expect busy waiting to make a difference
Re: The Curious Case of Beam CPU Usage (2019)
#6[dead]
Re: The Curious Case of Beam CPU Usage (2019)
#7been 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.
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, sin…
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
Re: The Curious Case of Beam CPU Usage (2019)
#8Earlier quoted context omitted.
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, sin…
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
> When coming from telephony and high availability [world]
That's a good point, its pretty easy to forget BEAM's heritage from the telecom world. The defaults on the VM are for that use-case, I'm so used to thinking of everything from a web perspective that I didn't even consider this, despite knowing of its history.