5

私は自分のイベントマシンベースのアプリケーションをruby-profでプロファイリングし、次のことを興味深いと感じました。

                  5.28 0.00 5.28 0.00 4/4 Mutex#synchronize
90.72%0.00%5.28 0.00 5.28 0.00 4 Mutex#sleep

ruby-profはCPUティックのみをカウントするため、ミューテックススリープにCPU時間がかかる理由を理解できません。ファイバー時間にはカウントされず、カーネルレベルでスリープすると思います。何か案は?さらに良いことに、Mutex#sleepがイベントマシンに制御を解放して、他のことを実行できるようにしたいと思います。

4

5 に答える 5

1

ruby-prof --mode = cpuが実際にはCPU時間を考慮しているだけの場合、Mutex#sleepはスピンロックです。

http://en.wikipedia.org/wiki/Spinlock

非常に短い割り当てをミューテックスロックでラップすることになっているだけなので、それは理にかなっています。信号アラームを設定することは非常識なオーバーヘッドになります。

したがって、直面する課題は、スリープしているミューテックスと、それらが何をラップするかを決定することです。次に、回避可能なミューテックスの乱用、または回避できない待機時間を発見します。

于 2011-11-06T15:28:27.730 に答える
0

その90%は、90%の時間「スリープ」していることを意味する場合があります[?]一般にEMでは、スリープする必要はなく、イベントに応答するだけで、CPUの大部分がEMの「実行」として表示されます。 " 方法

于 2011-04-11T20:47:20.180 に答える
0

通常、1 つのスレッドが何かを実行していて、2 番目のスレッドがその終了を待っている場合、そのスレッドはスリープしていると見なされます。したがって、スリープ時間は次のいずれかになります(スレッドによって異なります):-スレッドはイベントを待機しています(アイドル)-スレッドは別のスレッドが何かを完了するのを待っています(他のスレッドがビジーです)

于 2011-06-13T10:13:30.493 に答える
0

私の知る限り、ロックが解放されるのを待って立ち往生している場合、そのスレッドはスリープ モードで立ち往生しています。Eventmachine の実行を維持する唯一の方法は、ロックが別のスレッドで発生するようにすることです。

于 2011-04-11T16:15:45.380 に答える
0

正確な答えを出すには情報が少なすぎます。

ruby-prof が提供するパーセンテージを無視して、プロファイルが実際に実行される時間はどれくらいで、ミューテックスで実際に費やされる時間はどれくらいですか? これは、#defer スレッドまたは類似のもののみを示しており、別のスレッドの C++ ランタイムを完全に無視している可能性があります。

于 2011-09-28T17:59:47.483 に答える