3 ms·
Sounds like Discord was running gigantic in memory Go caches. Not that it's the wrong approach, but this is a very real-time system-y problem that Rust is desi
by cfors 6y ago
Sounds like Discord was running gigantic in memory Go caches.
Not that it's the wrong approach, but this is a very real-time system-y problem that Rust is designed for. So I understand why this made sense.
Obviously rewriting in Rust worked for them, but I'm curious if they tried the Ballast[0] approach, along with smaller cache's per service. That would make the GC scan on the cache smaller while still avoiding some of the Go startup heap issues. I'm not sure if the target heap size ever was accepted by the Go team, but it may have been easier than a full rewrite.
[0] https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i-learnt-to-stop-worrying-and-love-the-heap-26c2462549a2/ https://blog.twitch.tv/en/2019/04/10/go-memory-ballast-how-i...
- masklinn 6y ago> I'm curious if they tried the Ballast[0] approach From the essay, the issue discord had was that they were not triggering enough GCs. The ballast approach serves to tune the GC frequency down. In Discord's case they were getting screwed by a periodic mandatory GC trigger. > along with smaller cache's per service They did use a smaller cache, but that increased their 99% since… there was now less stuff in the cache.
- cfors 6y agoMakes me wonder what their partitioning strategy was. I can't imagine a cache that is over 4GB+ that couldn't be partitioned at least a bit further. But good call out, thank you for the correction.
- kyrra 6y agoThere's a proposal to put in official support for minimum heap size: https://github.com/golang/go/issues/44309 https://github.com/golang/go/issues/44309
- deleted 6y ago[deleted]