2009-09-08 2 views
8

Наше приложение имеет ~ 10 потоков, выполняющих отдельные задачи (без пулов потоков). Мы не сталкиваемся с тупиковой ситуацией, но всегда стараемся снизить задержку, чтобы ответить на запрос, поэтому мы заинтересованы в определении того, какие блокировки являются наиболее распространенными. jconsole показывает, как часто блокируются потоки, и это происходит не очень часто, но мы все же хотим знать, какие блокировки являются наиболее распространенными.Определение того, какие блокировки наиболее разрешены?

Мы работаем с использованием Sun JVM, поэтому JLA от IBM не полезна, и мы не работаем на Solaris, поэтому мы не можем использовать dTrace.

EDIT: Я хочу сделать это наблюдение в производстве, где профайлер замедлит приложение неприемлемо. Это торговая система, если мы медленны, мы теряем деньги, поэтому мы не запускаем профилировщики в производстве. Также довольно сложно моделировать многие обмены, с которыми мы беседуем в тесте производительности.

+0

dTrace - единственная система, которую я лично знаю о том, что делает то, что вы хотите, без инструментов профилирования. – aperkins

+0

Думая об этом больше, я считаю, что инструментарий - лучший подход. Вы можете регистрировать отдельные запросы блокировки или сохранять глобальные счетчики. –

ответ

7

Получите хороший профайлер, например YourKit. Он может рассказать вам, сколько времени затрачено на ожидание и блокирование определенных методов и мониторов объектов, содержащихся в нем. Например:

alt text http://i25.tinypic.com/j8ocbm.jpg


Что касается вашего комментария о производственных показателях, вы весьма ограничены в том, что вы можете собрать. Большая часть информации вы получите от ThreadMXBean, которая может дать вам метаданные обо всех работающих потоках. Однако он не даст вам информации о конкуренции конкретного монитора объекта.

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

Даже запуск профилировщика в условиях симулированной, но не совсем хорошей ситуации, вероятно, даст вам хорошую информацию.

+0

JProfiler имеет аналогичную функциональность. Но я хочу сделать это наблюдение на производстве, где профайлер будет замедлять приложение неприемлемо. Это торговая система, если мы медленны, мы теряем деньги, поэтому мы не запускаем профилировщики в производстве. Также довольно сложно моделировать многие обмены, о которых мы говорим, в среде тестирования производительности. –

+0

@Ted, я бы отредактировал ваш вопрос, чтобы добавить эту информацию, поскольку она резко изменяет то, что вы можете и чего не можете сделать. – Kevin

+0

Спасибо, Кевин, отредактирован. У нас есть среда для тестирования производительности, которая была очень полезной в прошлом, но я думаю, что большинство высокочастотных финансовых магазинов решили, что слишком много времени для моделирования реального мира неэффективно. Я буду искать сделку, в которой мы можем запустить профилировщик в производстве без особого ущерба. –

4

Для аналогичной проблемы в базе данных мы регистрируем строку непосредственно перед запросом и сразу после приобретения блокировки. Мы также регистрируем один после освобождения. Затем мы обрабатываем эти данные для создания типа статистики, которую вы ищете.

EDIT: В дополнение к разработанной системе AspectJ может быть хорошим вариантом для генерации журналов.

5

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

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

Без чего-то подобного, вы всегда будете сталкиваться с проблемой Гейзенберга: воздействовать на систему, которую вы измеряете.

Смежные вопросы