From: alexandre@...
Date: 2014-05-12T12:33:08+00:00
Subject: [ruby-core:62544] [ruby-trunk - misc #9832] better concurrency in	threads

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/