c3p0 Обнаружение взаимоблокировок - поток работает слишком часто

Мы используем пул соединений Hibernate и c3p0. Пока эта комбинация отлично работала до недавнего времени, когда мы решили увеличить maxPoolSize до 1000 и провести много стресс-тестов нашего приложения. Пиковая нагрузка нашего приложения приводит к тому, что БД очень медленно реагирует, и, как следствие, детектор тупиковых ситуаций c3p0 снова и снова выдает предупреждение APPARENT DEADLOCK.

Основываясь на документации c3p0, мы изменили maxAdministrativeTaskTime на 10 минут, предполагая, что обнаружение взаимоблокировок происходит каждые 30 минут (код указывает, что частота обнаружения взаимоблокировок в три раза выше, чем у maxAdministrativeTaskTime).

Однако при анализе журналов c3p0 поток обнаружения взаимоблокировок работает чаще, чем 30 минут. Соответствующая часть журналов прилагается. Удивительно, но частота не одинакова.

Line 573745: [Timer-2] 2013-06-26 04:47:52,492 WARN [null] com.mchange.v2.async.ThreadPoolAsynchronousRunner$DeadlockDetector@662cee3b -- APPARENT DEADLOCK!!! Creating emergency threads for unassigned pending tasks!
Line 573746: [Timer-2] 2013-06-26 04:47:52,512 WARN [null] com.mchange.v2.async.ThreadPoolAsynchronousRunner$DeadlockDetector@662cee3b -- APPARENT DEADLOCK!!! Complete Status: 
Line 574292: [Timer-2] 2013-06-26 04:49:12,493 WARN [null] com.mchange.v2.async.ThreadPoolAsynchronousRunner$DeadlockDetector@662cee3b -- APPARENT DEADLOCK!!! Creating emergency threads for unassigned pending tasks!
Line 574293: [Timer-2] 2013-06-26 04:49:12,513 WARN [null] com.mchange.v2.async.ThreadPoolAsynchronousRunner$DeadlockDetector@662cee3b -- APPARENT DEADLOCK!!! Complete Status: 
Line 575004: [Timer-2] 2013-06-26 04:50:32,494 WARN [null] com.mchange.v2.async.ThreadPoolAsynchronousRunner$DeadlockDetector@662cee3b -- APPARENT DEADLOCK!!! Creating emergency threads for unassigned pending tasks!
Line 575005: [Timer-2] 2013-06-26 04:50:32,511 WARN [null] com.mchange.v2.async.ThreadPoolAsynchronousRunner$DeadlockDetector@662cee3b -- APPARENT DEADLOCK!!! Complete Status: 
Line 576062: [Timer-2] 2013-06-26 04:51:52,495 WARN [null] com.mchange.v2.async.ThreadPoolAsynchronousRunner$DeadlockDetector@662cee3b -- APPARENT DEADLOCK!!! Creating emergency threads for unassigned pending tasks!
Line 576063: [Timer-2] 2013-06-26 04:51:52,536 WARN [null] com.mchange.v2.async.ThreadPoolAsynchronousRunner$DeadlockDetector@662cee3b -- APPARENT DEADLOCK!!! Complete Status: 
Line 576720: [Timer-2] 2013-06-26 04:53:12,496 WARN [null] com.mchange.v2.async.ThreadPoolAsynchronousRunner$DeadlockDetector@662cee3b -- APPARENT DEADLOCK!!! Creating emergency threads for unassigned pending tasks!
Line 576721: [Timer-2] 2013-06-26 04:53:12,516 WARN [null] com.mchange.v2.async.ThreadPoolAsynchronousRunner$DeadlockDetector@662cee3b -- APPARENT DEADLOCK!!! Complete Status: 
Line 594087: [Timer-2] 2013-06-26 04:55:52,550 WARN [null] com.mchange.v2.async.ThreadPoolAsynchronousRunner$DeadlockDetector@662cee3b -- APPARENT DEADLOCK!!! Creating emergency threads for unassigned pending tasks!
Line 594088: [Timer-2] 2013-06-26 04:55:52,569 WARN [null] com.mchange.v2.async.ThreadPoolAsynchronousRunner$DeadlockDetector@662cee3b -- APPARENT DEADLOCK!!! Complete Status: 
Line 594753: [Timer-2] 2013-06-26 04:57:12,550 WARN [null] com.mchange.v2.async.ThreadPoolAsynchronousRunner$DeadlockDetector@662cee3b -- APPARENT DEADLOCK!!! Creating emergency threads for unassigned pending tasks!
Line 594754: [Timer-2] 2013-06-26 04:57:12,572 WARN [null] com.mchange.v2.async.ThreadPoolAsynchronousRunner$DeadlockDetector@662cee3b -- APPARENT DEADLOCK!!! Complete Status: 
Line 595624: [Timer-2] 2013-06-26 04:58:32,552 WARN [null] com.mchange.v2.async.ThreadPoolAsynchronousRunner$DeadlockDetector@662cee3b -- APPARENT DEADLOCK!!! Creating emergency threads for unassigned pending tasks!
Line 595625: [Timer-2] 2013-06-26 04:58:32,570 WARN [null] com.mchange.v2.async.ThreadPoolAsynchronousRunner$DeadlockDetector@662cee3b -- APPARENT DEADLOCK!!! Complete Status: 
Line 596416: [Timer-2] 2013-06-26 04:59:52,552 WARN [null] com.mchange.v2.async.ThreadPoolAsynchronousRunner$DeadlockDetector@662cee3b -- APPARENT DEADLOCK!!! Creating emergency threads for unassigned pending tasks!
Line 596417: [Timer-2] 2013-06-26 04:59:52,572 WARN [null] com.mchange.v2.async.ThreadPoolAsynchronousRunner$DeadlockDetector@662cee3b -- APPARENT DEADLOCK!!! Complete Status: 
Line 611011: [Timer-2] 2013-06-26 05:02:22,556 WARN [null] com.mchange.v2.async.ThreadPoolAsynchronousRunner$DeadlockDetector@662cee3b -- APPARENT DEADLOCK!!! Creating emergency threads for unassigned pending tasks!
Line 611012: [Timer-2] 2013-06-26 05:02:22,577 WARN [null] com.mchange.v2.async.ThreadPoolAsynchronousRunner$DeadlockDetector@662cee3b -- APPARENT DEADLOCK!!! Complete Status:

Может кто-нибудь объяснить эту аномалию?


hibernate deadlock connection-pooling c3p0
person Vamsi Krishna    schedule 26.06.2013    source источник
comment
Ok. извините за мой первоначальный ответ ниже, который был не так хорош. я исправил ошибочную часть. если присмотреться теперь внимательнее, в этом есть много причудливого. Вы не только неожиданно часто сталкиваетесь с тупиками, но и сами видите тупиковые ситуации, которые вообще не должны были быть взаимоблокировками. Состояние «Завершено»: пусто. Должны быть дампы задач в пуле потоков и трассировки их стека. нет. (Обрезает ли ваш регистратор многострочные элементы журнала?)   -  person Steve Waldman    schedule 27.06.2013

Ответы (2)


arrow_upward
3
arrow_downward

maxAdministrativeTaskTime не влияет на детектор взаимоблокировок пула потоков; он просто ограничивает длину, которую разрешено выполнять одной задаче, прежде чем пул попытается ее interrupt(). один (хакерский !, уродливый !, не рекомендуется!) способ попытаться избежать ВНЕШНИХ БЛОКИРОВКИ - установить для него КОРОТКИЙ интервал, чтобы медленные задачи прерывались, а не зависали так долго, что пул решает, что застрял. Просмотрите некоторые обсуждения здесь.

благодаря автору (по электронной почте) я перепроверил свой% $ ^ * &! код, а интервал обнаружения взаимоблокировок зависит от maxAdministrativeTaskTime. как следует из вопроса, должно быть 3 maxAdministrativeTaskTime. так тайна углубляется.

Стоит разобраться, что делает детектор тупика. c3p0 поддерживает numHelperThreads большой пул потоков. детектор взаимоблокировок периодически отмечает все задачи, потоки в пуле выполняются, затем некоторое время засыпает, а затем снова проверяет. если ни одна из задач не завершена, т.е. активные задачи остаются такими же, как и во время последней проверки, то объявляется тупик. интервал, в течение которого c3p0 ожидает завершения некоторой задачи, составляет 10 секунд и пока не настраивается. его можно было сделать настраиваемым.

вы можете опубликовать несколько примеров ВНЕШНИХ БЛОКИРОВКИ, которые вы видите. c3p0 выводит много информации, чтобы помочь вам понять, что может зависнуть.

вот два предложения по сокращению ВНЕШНЕГО ТЕРМИНГА при очень большой нагрузке:

  1. Связаны ли наблюдаемые вами взаимоблокировки с подключением? Если это так, а если вы еще этого не сделали, обновитесь до c3p0-0.9.2.1 или последней предварительной версии 0.9.5.

  2. пробовали ли вы увеличивать numHelperThreads по мере увеличения нагрузки? если некоторые задачи выполняются очень медленно, c3p0 не будет объявлять тупик, если все потоки не будут заблокированы медленными задачами. если потоков достаточно, так что более гибкие задачи все еще выполняются, вы не увидите тупиковых ситуаций.

надеюсь, это поможет!

person Steve Waldman    schedule 27.06.2013

arrow_upward
1
arrow_downward

Я не могу это объяснить, но 1000 подключений - это довольно много, отражает ли ваша конфигурация c3p0 такое большое количество подключений? Мой опыт показывает, что настройки по умолчанию подходят для меньшего количества подключений. Я предлагаю прочитать документацию c3po, особенно часть в разделе «Другой источник данных» Конфигурация ».

person ChrisBlom    schedule 26.06.2013