Идентификация тупиков в потоке с помощью Firebird

Question

Разработчик ищет лучший способ для определения тупика в конкретной транзакции внутри определенного потока. Мы получаем ошибки взаимоблокировки, но они очень распространены в FB 2.0

Возникают взаимоблокировки, которые приводят к сбоям в соединении БД между клиентом и БД.

• Отправляем живые (раз в секунду) данные в БД.
• Мы открываем пул потоков из примерно 30 потоков и используем их для загрузки данных (около 1-2 КБ каждую секунду).
• Иногда БД может занимать только столько, что мы используем следующий поток в пуле, чтобы поддерживать поток в максимально возможной степени.

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

Так что нам действительно нужны мнения о том, является ли это лучшим методом для загрузки такого количества данных каждую секунду. У нас есть до 100 на этих клиентах, одновременно работающих с БД.
Среднее количество транзакций составляет от 1,5 до 1,8 миллиона в день.

Answer 1

В 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

Answer 2

Я не знаю конкретного способа идентификации конкретного потока или оператора. Мне приходилось сталкиваться с тупиками FB много раз. Возможно, у вас есть две команды, которые пытаются обновить одну и ту же строку в некоторой таблице, но они делают это в отдельных транзакциях.

Лучшее решение, которое я нашел, - это спроектировать вещи так, чтобы потоки никогда не обновляли строку, которую мог бы обновить любой другой поток. Иногда это означает наличие потока, который просто существует для обновления общей таблицы / строки. Рабочие потоки отправляют сообщение в эту тему. (Сообщение может быть сделано через другую таблицу.)

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

Answer 3

Я бы предложил написать 3-уровневое приложение, сериализовать весь доступ к базе данных (вставить) в один поток (другие потоки просто складывают данные в очереди) и использовать встроенный Firebird (что гораздо быстрее, потому что устраняет накладные расходы TCP / IP).

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