[#60404] is RB_GC_GUARD needed in rb_io_syswrite? — Eric Wong <normalperson@...>
I haven't gotten it to crash as-is, but it seems like we need to
4 messages
2014/02/01
[#60682] volatile usages — Eric Wong <normalperson@...>
Hi all, I went ahead and removed some use of volatile which were once
5 messages
2014/02/13
[#60794] [RFC] rearrange+pack vtm and time_object structs — Eric Wong <normalperson@...>
Extracted from addendum on top of Feature #9362 (cache-aligned objects).
4 messages
2014/02/16
[#61139] [ruby-trunk - Feature #9577] [Open] [PATCH] benchmark/driver.rb: align columns in text output — normalperson@...
Issue #9577 has been reported by Eric Wong.
3 messages
2014/02/28
[ruby-core:60849] [ruby-trunk - Feature #9113] Ship Ruby for Linux with jemalloc out-of-the-box
From:
normalperson@...
Date:
2014-02-19 00:00:52 UTC
List:
ruby-core #60849
Issue #9113 has been updated by Eric Wong.
sam.saffron@gmail.com wrote:
> An artificial test is:
>
> @retained = []
>
> MAX_STRING_SIZE = 100
>
> def stress(allocate_count, retain_count, chunk_size)
Note: I think we should seed the RNG to a constant to have
consistent data between runs
srand(123)
> chunk = []
> while retain_count > 0 || allocate_count > 0
> if retain_count == 0 || (Random.rand < 0.5 && allocate_count > 0)
> chunk << " " * (Random.rand * MAX_STRING_SIZE).to_i
> allocate_count -= 1
> if chunk.length > chunk_size
> chunk = []
> end
> else
> @retained << " " * (Random.rand * MAX_STRING_SIZE).to_i
> retain_count -= 1
> end
> end
> end
Sam: Thank you!
I think we should integrate this test into the mainline benchmark suite.
Perhaps even provide an option to run with all the existing tests with
the big @retained array.
ko1: what do you think?
----------------------------------------
Feature #9113: Ship Ruby for Linux with jemalloc out-of-the-box
https://bugs.ruby-lang.org/issues/9113#change-45263
* Author: Sam Saffron
* Status: Feedback
* Priority: Normal
* Assignee:
* Category: build
* Target version:
----------------------------------------
libc's malloc is a problem, it fragments badly meaning forks share less memory and is slow compared to tcmalloc or jemalloc.
both jemalloc and tcmalloc are heavily battle tested and stable.
2 years ago redis picked up the jemalloc dependency see: http://oldblog.antirez.com/post/everything-about-redis-24.html
To quote antirez:
``
But an allocator is a serious thing. Since we introduced the specially encoded data types Redis started suffering from fragmentation. We tried different things to fix the problem, but basically the Linux default allocator in glibc sucks really, really hard.
``
---
I recently benched Discourse with tcmalloc / jemalloc and default and noticed 2 very important thing:
median request time reduce by up to 10% (under both)
PSS (proportional share size) is reduced by 10% under jemalloc and 8% under tcmalloc.
We can always use LD_PRELOAD to yank these in, but my concern is that standard distributions are using a far from optimal memory allocator. It would be awesome if the build, out-of-the-box, just checked if it was on Linux (eg: https://github.com/antirez/redis/blob/unstable/src/Makefile#L30-L34 ) and then used jemalloc instead.
--
http://bugs.ruby-lang.org/