Oh got it, I should outline more of the problem we faced.
We had a high throughput server that needed a fair amount of in memory data to service the requests. The in memory data would update, one set of the data would update very quickly while the larger data set would update slowly.
Two things on this:
1) Ruby is not concurrent, it is multi-threaded but not concurrent. When ruby starts up you generally create a new process per CPU to ensure you can utilize all cpus. This is generally fine for a CRUD app but does not work well if you really need to share in memory data structures in a low latency way, it will result in any changes to memory being repeated for each process, so a 32 core machine is 1/32 as efficient with memory.
2) Ruby, at least at the time, had a non-compacting garage collector. This over time leads to memory fragmentation which ends up causing ruby to run out of pages, as such you run out of ram. This mean with Ruby you have to be careful if you get closer to the limit of how much ram you have on a machine and you are allocating/freeing large spans of memory, if freeing memory doesn't free the page you can still run out of memory. This appears as a memory leak for the machine but ruby appears to still just be using the same amount of memory. Only fix for this is having rolling restarts. Java using a compacting garage collector, which can help alleviate this issue, of course it does come with some pauses.
I also found the ruby schedule is not pre-emptive. This might have changed but at the time it meant if you had a lot of threads that were waiting on external IO that the ruby machine's performance deteriorated. Java's scheduled appeared to be more performant. Looking at this post makes me realize I should turn this into a blog post with links to the actual numbers to demonstrate each issue clearly.
