Mutex сон занимает много процессора

Question

Я профилировал свое приложение на основе событий с помощью 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 считает только такты процессора, и, следовательно, я не могу понять, почему мьютексный сон может занимать процессорное время. Я предположил бы, что это спит на уровне ядра, не считая времени волокна. Есть идеи? Более того, я бы хотел, чтобы Mutex # sleep передавал управление машине событий, чтобы он мог выполнять другие функции.

Answer 1

Если ruby-prof --mode = cpu действительно учитывает только процессорное время, тогда Mutex # sleep является спин-блокировкой:

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

Это имело бы смысл, потому что вы должны заключать очень короткие назначения в блокировки мьютекса. Установка сигнала тревоги будет безумной накладной расходы.

Итак, перед вами стоит задача определить мьютексы, на которых вы спите, и что они обертывают. Затем вы обнаружите, как избежать злоупотребления мьютексом, или неизбежного времени ожидания.

Answer 2

Здесь слишком мало информации, чтобы дать точный ответ, однако я бы посоветовал взглянуть на несколько других аспектов, например, отслеживает ли ruby-prof время, проведенное в реакторе?

Независимо от того, какой процент дает вам ruby-prof, как долго фактически работает ваш профиль и сколько времени фактически проходит в мьютексе?Вероятно, это только показывает потоки #defer или что-то подобное, и полностью игнорирует среду выполнения C ++ в другом потоке.

Answer 3

что 90% может означать, что вы "спите" 90% времени [?] В общем, с EM вам не нужно спать, вы просто реагируете на события, и большинство процессоров будут отображаться какМетод пробежки ЭМ

Answer 4

Обычно, если один поток что-то делает, а второй ожидает его завершения, он будет рассматриваться как спящий. Таким образом, ваше время sleep может быть любым (в зависимости от вашего потока): - ваш поток ожидает события (в режиме ожидания) - ваш сервер ожидает, когда другой поток завершит что-то (другой поток занят)

Answer 5

Насколько я знаю, если вы застряли в ожидании снятия блокировки, этот поток застрял в спящем режиме. Единственный способ сохранить работу Eventmachine - убедиться, что ваши блокировки происходят в отдельном потоке.