ID-ing Тупики в потоке с использованием Firebird

Question

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

Ошибки блокировки, которые приводят к сбоям в соединении БД между клиентом и БД.

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

В некоторых случаях это создает тупик в дополнение к максимальному количеству потоков и нарушению соединения.

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

Answer 1

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

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

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

Answer 2

В 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 3

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

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