Hacker News new | past | comments | ask | show | jobs | submit login

The beam just garbage collects each actor separately, and it so happens that much of the time your actor has finished before a gc happened so you never see the cleanup.

The beam also has a spectacular failure mode: OOM whenever messages come in at a higher rate than they are processed. The lack of backpressure mechanisms mean a huge amount of beam language developers spend way too much time recreating their own way for dealing with this or pretend it is not a problem at all. This means too many libraries in the ecosystem behave totally differently under load.




I can see how you would think that, yes. In practice I haven't noticed it except in super rare cases where processes (actors) hold on to huge binaries / strings -- which is one of the weak points of BEAM's GC.


I've been bit by this. In reality you need to know your shit when it comes to tuning the Beam and GC to achieve decent performance under load without triggering OOM.


Not denying it, yeah, it's a blind spot and it's one of the more advanced topics when you start having actually loaded nodes in production.


The big offenders is serializing huge jsons and chucking small binaries slices from that into an ets table.

Also concatenating binaries. Don't do that, use an iolist


Yep. Has bitten me in the bottom before.


My experience of this is not theoretical.


Maybe you should write a blog post about it, many in the Elixir's ecosystem are very serious devs and are always looking at ways to improve it.


There are entire github repos dealing with it.

Frankly the Elixir ecosystem, which is not without merit, is more interested in perpetuating the myth of magic scalability by virtue of the beam.


Frankly I am seeing that as a myth, you seem to have made up your mind some time ago or judged by 1-2 occasions.

I am on ElixirForum every day and worked with Elixir for 7 years and have never seen anyone "perpetuate myths". I've seen some people willing to "increase adoption" which was always met with resistance by the wider community -- we believe growth should be organic.

Pretty sad stance from you though, I have no idea why people get so ticked off when another programmer wants to tell them about a secret weapon.

If you are not willing to try it, that's fair. Say that. Claiming you know stuff about the ecosystem while a guy who is there every day is not seeing that at all comes across as... strange. Biased. And not arguing in good faith. :(


> If you are not willing to try it, that's fair. Say that. Claiming you know stuff about the ecosystem while a guy who is there every day comes across as... strange. Biased. And not arguing in good faith. :(

I am not willing to drag others, such as those that wrote the repos, into a technical discussion with people out to act as you are.


I really don't get your replies and why their tone has to be the way it is but, have it your way. I tried.


The guy you are responding to was completely calm and reasonable. Didn't say anything attacking or otherwise. I'm not sure why you are seemingly trying to cast him (and the Beam) in such a bad light, with seemingly no reason to back it up.


He is adopting the missionary tactic of feigning a desire for discussion when it is just veiled evangelism.


He seemed to be asking you to back up your claims and you seem to be just saying claiming that you don't need to and he is the problem...


Both of you are afflicted by that logical fallacy of failing to understand that you not encountering a phenomenon does not mean it does not happen or is rare, it just means you didn't encounter it.

If you try telling people that did encounter that phenomenon that in practice they wouldn't/didn't then you shouldn't be surprised if they question why they started talking to you in the first place.


Yeah but when you don't have any evidence and just accuse him baselessly as you have been... well...


Do you genuinely fail to see how your behaviour proves my point?

You cannot just hound people with demands because you don’t like what they are saying.


> Do you genuinely fail to see how your behaviour proves my point?

I genuinely see only one thing: I asked you to elaborate but you are convinced that I am pretending to discuss while I, again genuinely, actually did want to discuss.

You asserting something about me, a person whose mind you cannot read is confusing and quite aggressive, in a very uncalled-for manner too. But as I said already -- have it your way, I disengaged because it became apparent you are not interested in discussing. OK. It's your right.

What's not OK is you claiming that I am not interested in discussing however, and I maintain that I was interested in discussing.

> You cannot just hound people with demands because you don’t like what they are saying.

1. I am not "hounding" you for anything, I asked a question.

2. You are again assuming my motivation and I assert that you have gotten it wrong. You that I "disliked what you said" is a borderline personal attack and an off-topic. I was confused why you claimed what you did and wanted you to elaborate, to find out what made you think like that and if I can change your mind with a few anecdotes and some facts (that are hard to look up because they require scanning a forum; yet they are there and are visible to everyone who engages with the platform).

BTW, if you really have known anything at all about the Elixir ecosystem you would know that its creator, to this day, engages with users on ElixirForum and asks for their feedback on what they find lacking. That sort of engagement and genuine discussion spirit that you claim I (as a part of the Elixir community) don't have.

That alone invalidates your point entirely.

I am disengaging second and final time, let future readers decide for themselves.


Calling someone “biased” and “acting in bad faith” is a personal attack and violates this site’s rules. People get rate limited for far less on this site.


I'd argue taking things out of context and deliberately painting the commenter in a bad light is not a nice forum discourse.

I said, very plainly and visibly, that my parent commenter's unwillingness to back up negative claims COMES ACROSS as biased and ARGUING (NOT "acting") in bad faith.

Come on now, this stuff is not hard, the message is literally up there. Not sure why you had to editorialize it and thus misconstrue it?


He didn't call him that at all. He said him being unwilling to explain his points and instead just making claims comes across that way.

He at no time called him biased or said he was directly acting in bad faith


> Biased. And not arguing in good faith. :(


You are leaving the prior part of his sentence out. Regardless, Before he said that you weren't willing to answer either.


You are both gaslighting.

As I plainly explained, right at the top, it is not theoretical. There is no point engaging people with evidence if they are so dismissive of basic facts.

But then that is also true here. Your claims about him not saying what he plainly did are just bizarre.


I think that's developers using GenServer.cast when they should be using call. Call gives you back pressure mechanism.


TBH at the load we had we got substantial savings by eventually replacing usage of gen_server as well, though that probably isn’t a good idea much of the time.

The OOMs were largely being caused by calls to and from other services (i.e. kafka) so the answer proved to be in controlling the rate at which things come in and out at the very edge.

From what I saw I got the impression the Beam devs assumed memory and CPU usage go together so a system that is under load memory wise would also be CPU wise, but this isn’t the case if your fan out and gather involves holding large* values on which the response is based, even if for tiny amounts of time.

EDIT: *large meaning "surprisingly small" if you're coming from other universes.


This sounds like ets tables holding on to binaries that were extracted from JSON. This is something that iirc pager duty ran into.


The underlying problem we had* was the rate work was being completed was lower than the rate requests were coming in which causes the mailboxes on the actors to grow indefinitely.

In golang the approximate equivalent is a buffered channel that would start blocking because it has run out, but the beam will just keep those messages piling on to the queue as fast as possible until OOM. This is obviously a philosophical tradeoff.

* I should qualify that each request here had a life in low double digit ms, but there were millions of them per second, and these were very big machines.


Why weren't your processes dropping messages? Also I think you can tell the VM to not allow the process to exceed a certain message size and trigger some sort of rate limiting or scaling out

Edit: huh. I could swear the VM had memory limit options. Guess not. Time to rewrite it in zig!


Yeah, I think that's the assumption people had been operating under.

That team would have thoroughly endorsed a zig rewrite! It was a very odd situation where most of us liked erlang the language but found the beam to be an annoying beast, whereas most of the world seems to be the opposite.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: