Идентификация взаимоблокировок в потоке с помощью Firebird
Разработчик ищет лучший метод выявления тупиковой ситуации для конкретной транзакции внутри определенного потока. Мы получаем ошибки взаимоблокировки, но они очень общие в FB 2.0.
Возникают взаимоблокировки, которые приводят к сбоям в соединении БД между клиентом и БД.
- Отправляем живые (раз в секунду) данные в БД.
- Мы открываем пул потоков примерно из 30 потоков и используем их для приема данных (примерно 1-2 КБ каждую секунду).
- Иногда БД может занять столько, что мы используем следующий поток в пуле, чтобы поддерживать поток в актуальном состоянии, насколько это возможно.
Иногда это приводит к тупиковой ситуации в дополнение к достижению максимального количества потоков и разрыву соединения.
Так что нам действительно нужно мнение о том, является ли это лучшим способом получать такой объем данных каждую секунду. У нас до 100 клиентов одновременно обращаются к БД. В среднем транзакции составляют от 1,5 до 1,8 миллиона в день.
Ответы 3
Я не знаю конкретного способа идентифицировать конкретный поток или утверждение. Мне много раз приходилось сталкиваться с тупиками FB. У вас, вероятно, есть две группы, которые пытаются обновить одну и ту же строку в какой-то таблице, но делают это в разных транзакциях.
Лучшее решение, которое я нашел, - это спроектировать такие вещи, чтобы потокам никогда не приходилось обновлять строку, которую может обновить любой другой поток. Иногда это означает наличие потока, который существует только для обновления общей таблицы / строки. Рабочие потоки отправляют сообщение этому потоку. (Сообщение можно передать через другую таблицу.)
Мы запускаем FB во многих системах в этой области, которые генерируют транзакции (а не миллионы в день), и мы обнаружили, что FB надежен, как только мы разработали правильный дизайн.
В Firebird 2.1 есть новые возможности мониторинга таблиц, соединений и транзакций, возможно, это поможет вам (если вы сможете обновить). См. README.monitoring_tables.txt.
Пример получения активных операторов:
SELECT ATT.MON$USER, ATT.MON$REMOTE_ADDRESS, STMT.MON$SQL_TEXT, STMT.MON$TIMESTAMP
FROM MON$ATTACHMENTS ATT
JOIN MON$STATEMENTS STMT ON ATT.MON$ATTACHMENT_ID = STMT.MON$ATTACHMENT_ID
WHERE ATT.MON$ATTACHMENT_ID <> CURRENT_CONNECTION AND STMT.MON$STATE = 1
Мое предложение состояло в том, чтобы написать трехуровневое приложение, сериализовать весь доступ к базе данных (вставка) в один поток (другие потоки просто складывали бы данные в очередь) и использовать встроенный Firebird (что намного быстрее, потому что он исключает TCP / Накладные расходы IP).
Помимо предотвращения тупиковых ситуаций, этот подход также позволит вам контролировать очередь и видеть, как система способна справиться с нагрузкой.
Я голосую против, потому что не думаю, что доступ к базе данных с ограниченным доступом к одному потоку является правильным ответом на этот конкретный вопрос. Основная причина, по которой вы используете модель сервера Firebird вместо встроенной библиотеки, - это поддержка нескольких одновременно работающих клиентов. Они уже зависят от этой функции Сервиса. Недавно мы перешли к нему (от встроенного), чтобы пользовательский интерфейс и служба могли напрямую обращаться к данным, уменьшая накладные расходы на сериализацию между компонентами, как только один пример использования.
Чем больше у вас одновременно клиентов, тем выше вероятность тупиковой ситуации. Я согласен с вашим комментарием, когда у вас есть несколько независимых операций, которые могут выполняться одновременно, но в этом случае вопрос заключался в том, как обрабатывать параллельные операции, которые блокируют друг друга.
Я думаю, что это такой же точный ответ, как и любой другой - мы некоторое время работали с Firebird, и кажется, что внимание к деталям в хранимых процедурах в конечном итоге уменьшает или устраняет проблему. Я также порекомендовал бы IBExpert для мониторинга - их лицензия на одно рабочее место разработчика стоит недорого, а их набор функций впечатляет.