[ruby-core:62544] [ruby-trunk - misc #9832] better concurrency in threads

Issue #9832 has been updated by Alexandre Riveira.


cougar =3D> puma

----------------------------------------
misc #9832: better concurrency in threads
https://bugs.ruby-lang.org/issues/9832#change-46696

* Author: Alexandre Riveira
* Status: Open
* Priority: Normal
* Assignee:=20
* Category:=20
* Target version:=20
----------------------------------------
My application runs on top of rainbows using workers with multi-threaded.
I realized that in ruby =E2=80=8B=E2=80=8Brunning on linux (my kernel confi=
g 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 distri=
buted processing equally
So when the road test with ruby 1.9.2 on linux it does not perform.
This improved in ruby =E2=80=8B=E2=80=8B1.9.3 and further in ruby =E2=80=8B=
=E2=80=8B2.0.
But it still is not the ideal

My tests:
ruby 1.9.2p320 =3D> not work=20
ruby 1.9.3p545 =3D> 68 secs
ruby 2.0.0p451 =3D> 29 secs
ruby 2.1.2p95  =3D> 29 secs=20

ruby without GVL workfine
rubinius 2.2.6 =3D> 21 secs
jruby 1.7.12 =3D> 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 =E2=80=8B=E2=80=8B1.9.2

ruby 1.9.2p320 =3D> 21 secs=20
ruby 1.9.3p545 =3D> 30 secs
ruby 2.0.0p451 =3D> 23 secs
ruby 2.1.2p95  =3D> 23 secs=20

This reflects directly in the application, if one thread is is using 100% c=
pu with rainbows application begins to degrade coming to answer the other t=
hreads 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}`
=20=20
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 =E2=80=
=8B=E2=80=8BI am grateful for any help for=20
fixing the process taskset on a particular processor which is not ideal.






---Files--------------------------------
test_thread_schedule.rb (955 Bytes)


--=20
https://bugs.ruby-lang.org/