Prev: [ANN] Inochi 2.0.1
Next: [ANN] jruby_gc_stats 0.1: a set of GC monitoring methods similar toREE
From: Raul Parolari on 27 Apr 2010 18:15
Walton Hoops wrote:
> On 4/27/2010 12:01 PM, Raul Parolari wrote:
>>..
>> So, Ruby is above our hopes ("in average") for high speed comm, but it
>> is not predictable (the maximum delay in the above example being 25
>> times the average, which would force us to set the timeouts absurdly
>> high). Something happens inside Ruby once in a while which freezes it;
>> from here, my suspicion of the garbage collector.
>>
>
> A quick way to confirm that would be to disable garbage collection via
> GC.disable(). Of course this will result in a memory leak, but is the
> best way to test for sure if the GC is the problem. If it turns out
> that it is, indeed the GC, you could just disable it for the critical
> sections.

Walton

excellent suggestion; I will try it as soon as I can.

While the move to C++ may not reversible for us, I still want to know
the whole Ruby story on this point; and I will report back.

Thanks

Raul
--
Posted via http://www.ruby-forum.com/.

From: Caleb Clausen on 28 Apr 2010 10:06
On 4/27/10, Raul Parolari <raulparolari(a)gmail.com> wrote:
> can you point out a link to how to do that (making GC to happen every
> time?); I found pages which mention setting Ruby Constants, but let me
> know what is the best page if you have the chance.

Just call GC.start inside your main loop somewhere. Like right before
or after the call to recv.

First  |  Prev  | 
Pages: 1 2
Prev: [ANN] Inochi 2.0.1
Next: [ANN] jruby_gc_stats 0.1: a set of GC monitoring methods similar toREE