Misc #9832
openbetter concurrency in threads
Description
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