Симонов Денис
пока что только через fb_lock_print

Спасибо, там действительно сложно разобраться без опыта.

а ещё блокировки происходят когда дёргаешь один и тот же генератор (последовательность).

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

Число записей на страницу примерно можно посчитать, при размере 8k и таблице из двух строк (integer + varchar), например ('1', 'Здесь мое имя') делим размер на длину записи. Примерно, конечно.

Какие настройки кэширования в файле firebird.conf? ForceWrites для базы включен/выключен?

Не нашел такого параметра. Как я понял, по уполчанию он включен.

С автокоммитом небось ?

Да, с автокоммитом. Если без автокоммита и вручную делать коммит в jmeter, то при одинаковых тестах падает число IOPS, тогда как задача заставить базу выжимать максимум.



============


Сделал 10 таблиц по миллиону записей в каждой. Построил индекс по полю integer и запустил update t1..10 set name='xxxxxxxxx' where id = ? , где вместо ? идет переменная от 1 до миллиона. По идее при таком режиме не должны быть блокировки на уровне страницы, т.к. апдейты равномерно распределяются по десяти таблицам.

После запуска теста чуть-чуть увеличилось число IOPS, порядка 2600. По сути разницы между последовательным INSERT и случайным update нет, что очень странно. На всякий случай проверил таблицы, в них действительно в случайном порядке изменились записи, так что тест работает как надо.

fb_lock_print посмотрел, но мало что в нем понял, Mutex wait стоит 0.4%.