Misc #9832


better concurrency in threads

Added by ariveira (Alexandre Riveira) about 8 years ago. Updated about 8 years ago.



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 #{})
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


before_fork do |server, worker|
taskset -c -p 2 #{}


on_worker_boot do |index|
taskset -c -p 2 #{}

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.


test_thread_schedule.rb (955 Bytes) test_thread_schedule.rb ariveira (Alexandre Riveira), 05/12/2014 11:47 AM

Also available in: Atom PDF