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

Я профилировал свое приложение, основанное на машине событий, с помощью 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 передал управление машине событий, чтобы она могла делать другие вещи.


ruby mutex ruby-prof eventmachine
person Prasanna    schedule 20.03.2011    source источник

Ответы (5)


arrow_upward
1
arrow_downward

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

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

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

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

person sheldonh    schedule 06.11.2011

arrow_upward
0
arrow_downward

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

person tadman    schedule 11.04.2011

arrow_upward
0
arrow_downward

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

person rogerdpack    schedule 11.04.2011

arrow_upward
0
arrow_downward

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

person mb14    schedule 13.06.2011

arrow_upward
0
arrow_downward

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

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

person raggi    schedule 28.09.2011