Firebird замедляет работу, пока доступны ресурсы

У меня странная проблема с замедлением работы с базой данных Firebird. Во время ежедневного использования базы данных клиенты испытывают значительные замедления, в то время как в системе все еще доступно много ресурсов. Немного информации об окружающей среде:

• 64-битный сервер Firebird 2.5.2, работающий в режиме SuperServer
• база данных работает на 64-битной серверной ОС Windows 2008 R2
• ОС сервера работает на виртуальной машине VMware 4.1 с 4 ядрами ЦП и 16 ГБ ОЗУ
• размер базы данных составляет около 37 ГБ, а количество одновременных подключений к базе данных составляет около 150.

Наблюдая за замедлениями:

• загрузка ЦП на машине составляет от 40 до 60% без резких скачков, а нагрузка хорошо распределяется между всеми 4 ядрами.
• использование памяти сервера составляет около 4-6 ГБ, а остальная память используется как кеш ОС
• длина очереди диска почти никогда не превышает 0,3 с задержкой около 2-5 мс
• на сервере практически отсутствует сетевая активность.

Тем не менее, похоже, что замедление связано с общей нагрузкой на сервер. Ночью, когда к базе данных не подключены пользователи / не запущены фоновые задания, тестовый запрос, используемый для справки, выполняется в течение 4-5 секунд, в то время как днем, когда все пользователи подключены к базе данных, для выполнения одного и того же справочного запроса требуется 60+ секунд до конца. Однако следует добавить, что замедление носит общий характер, нет конкретных запросов, которые выполняются медленнее, пока сервер находится под нагрузкой, все становится медленнее в конкретной базе данных Firebird. На сервере есть другие базы данных с очень низким количеством транзакций, выполняемых ежедневно, и эти другие базы данных не показывают никаких признаков замедления. Я даже создал копию живой базы данных, в которой наблюдается замедление, и выполнил один и тот же запрос как для исходной, так и для дублированной базы данных - оригинал действительно выполнял запрос медленно, а дубликат быстро. Единственная разница между оригиналом и дубликатом, которую я знаю, - это количество подключенных пользователей / одновременных транзакций.

Поскольку я не нашел явных причин всего этого в доступных ресурсах ОС, я попытался получить статистику из Firebird.

Наблюдения:

• в часы пик в базе данных параллельно выполняется 30-40 транзакций согласно инструкциям mon $ (где mon $ state == 1, что согласно архивам означает, что транзакции выполняются или ожидают блокировки)
• fb_lock_print отображает следующее о базе данных:

LOCK_HEADER BLOCK

    Version: 145, Active owner:      0, Length: 2097152, Used: 1335440
    Flags: 0x0001
    Enqs: 9993237, Converts:  93191, Rejects: 1417230, Blocks:      2
    Deadlock scans:      0, Deadlocks:      0, Scan interval:  10
    Acquires: 19972846, Acquire blocks:      0, Spin count:   0
    Mutex wait: 0.0%
    Hash slots: 1009, Hash lengths (min/avg/max):    0/   2/   7
    Remove node:      0, Insert queue:      0, Insert prior:      0
    Owners (38):    forward:  20824, backward: 872088
    Free owners (126):      forward: 973360, backward: 728016
    Free locks (370):       forward: 852200, backward: 195936
    Free requests (12425):  forward: 614608, backward: 1230536
    Lock Ordering: Enabled

Здесь я заметил, что поле «отклоняет» составляет ~ 14% от поля «enqs», но, к сожалению, я не знаю точного значения этих значений. Я думаю, что около 14% запросов на блокировку по какой-то причине отклоняются, но я могу ошибаться.

Итак, вопросы:

• Как следует интерпретировать вывод fb_lock_print в этом случае? Эти числа в каком-то смысле «неправильные»? Можно ли их улучшить, настроив параметры?
• Какие дополнительные шаги необходимо предпринять, чтобы точно определить причины замедления?