[#62297] Re: [ruby-cvs:52906] nari:r45760 (trunk): * gc.c (gc_after_sweep): suppress unnecessary expanding heap. — Eric Wong <normalperson@...>
nari@ruby-lang.org wrote:
7 messages
2014/05/02
[#62307] Re: [ruby-cvs:52906] nari:r45760 (trunk): * gc.c (gc_after_sweep): suppress unnecessary expanding heap.
— SASADA Koichi <ko1@...>
2014/05/03
(2014/05/03 4:41), Eric Wong wrote:
[#62402] Re: [ruby-cvs:52906] nari:r45760 (trunk): * gc.c (gc_after_sweep): suppress unnecessary expanding heap.
— Eric Wong <normalperson@...>
2014/05/05
SASADA Koichi <ko1@atdot.net> wrote:
[#62523] [ruby-trunk - Feature #9632] [PATCH 0/2] speedup IO#close with linked-list from ccan — ko1@...
Issue #9632 has been updated by Koichi Sasada.
3 messages
2014/05/11
[#62556] doxygen (Re: Re: [ruby-trunk - Feature #9632] [PATCH 0/2] speedup IO#close with linked-list from ccan) — Tanaka Akira <akr@...>
2014-05-11 8:50 GMT+09:00 Eric Wong <normalperson@yhbt.net>:
3 messages
2014/05/13
[#62727] [RFC] vm_method.c (rb_method_entry_make): avoid freed me in m_tbl — Eric Wong <normalperson@...>
rb_unlink_method_entry may cause old_me to be swept before the new
7 messages
2014/05/24
[#63039] Re: [RFC] vm_method.c (rb_method_entry_make): avoid freed me in m_tbl
— SASADA Koichi <ko1@...>
2014/06/10
Hi,
[#63077] Re: [RFC] vm_method.c (rb_method_entry_make): avoid freed me in m_tbl
— Eric Wong <normalperson@...>
2014/06/10
SASADA Koichi <ko1@atdot.net> wrote:
[#63086] Re: [RFC] vm_method.c (rb_method_entry_make): avoid freed me in m_tbl
— SASADA Koichi <ko1@...>
2014/06/11
(2014/06/11 4:47), Eric Wong wrote:
[#63087] Re: [RFC] vm_method.c (rb_method_entry_make): avoid freed me in m_tbl
— Eric Wong <normalperson@...>
2014/06/11
SASADA Koichi <ko1@atdot.net> wrote:
[#62862] [RFC] README.EXT: document rb_gc_register_mark_object — Eric Wong <normalperson@...>
Any comment on officially supporting this as part of the C API?
5 messages
2014/05/30
[ruby-core:62544] [ruby-trunk - misc #9832] better concurrency in threads
From:
alexandre@...
Date:
2014-05-12 12:33:08 UTC
List:
ruby-core #62544
Issue #9832 has been updated by Alexandre Riveira.
cougar => puma
----------------------------------------
misc #9832: better concurrency in threads
https://bugs.ruby-lang.org/issues/9832#change-46696
* Author: Alexandre Riveira
* Status: Open
* Priority: Normal
* Assignee:
* Category:
* Target version:
----------------------------------------
My application runs on top of rainbows using workers with multi-threaded.
I realized that in ruby running on linux (my kernel config is slackware, debian not work)
not equal to distribute the processing threads.
To test this I created the file that is attached test_thread_schedule.rb
The more the final test result is between 20/21 seconds means he has distributed processing equally
So when the road test with ruby 1.9.2 on linux it does not perform.
This improved in ruby 1.9.3 and further in ruby 2.0.
But it still is not the ideal
My tests:
ruby 1.9.2p320 => not work
ruby 1.9.3p545 => 68 secs
ruby 2.0.0p451 => 29 secs
ruby 2.1.2p95 => 29 secs
ruby without GVL workfine
rubinius 2.2.6 => 21 secs
jruby 1.7.12 => 21 secs
But if I apply taskset (uncomment line in the test file `taskset -c -p 2 #{Process.pid}`)
the results are noticeably better especially in ruby 1.9.2
ruby 1.9.2p320 => 21 secs
ruby 1.9.3p545 => 30 secs
ruby 2.0.0p451 => 23 secs
ruby 2.1.2p95 => 23 secs
This reflects directly in the application, if one thread is is using 100% cpu with rainbows application begins to degrade coming to answer the other threads 7-16 seconds based time passes. Taskset already applied it decreases considerably. The same test applied cougar, gets to be virtually no impact, but since taskset is applied to the process, follow my code
rainbows:
before_fork do |server, worker|
`taskset -c -p 2 #{Process.pid}`
puma:
on_worker_boot do |index|
`taskset -c -p 2 #{Process.pid}`
Could internally ruby linux treat in a special way so that the behavior of threads is improved ???
If this behavior can not be improved through a new feature in ruby I am grateful for any help for
fixing the process taskset on a particular processor which is not ideal.
---Files--------------------------------
test_thread_schedule.rb (955 Bytes)
--
https://bugs.ruby-lang.org/