@gargron The answer is "using Ruby", obviously!


@keithzg The answer is malloc's overallocation default due to RedHat's preferences and malloc's failure to return free empty heaps as a performance precaution

This is why you don't get memory issues when using jemalloc instead of glibc's malloc

@gargron Yeah to be honest I did read through it and found it very interesting, especially how apparently patching a malloc_trim() call into Ruby 2.6 actually *improved performance* in addition to reducing memory consumption.

Also very interesting, as you point out, is the somewhat warping influence Red Hat has on the default state and configuration of the underlying software stack.



Hey now, surely we can come together and all agree that Unix-style OSes are far better at this than Windows, for which similar situations tend to break down into "where did this memory go and who even requested it? Literally no way to ever tell, I guess just reboot periodically!"

@keithzg @Gargron I am not sure I know enough about Windows memory allocator here.

From what I see this is a remnant from brk()/sbrk()-style memory allocation, which is deeply rooted in UNIX history and memory segmentation.

Paging is clearly more difficult to manage.

Sign in to participate in the conversation

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!