Замедление Firebird, пока ресурсы доступны

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

• 64-битный сервер Firebird 2.5.2, работающий в режиме SuperServer
• база данных работает на 64-битной операционной системе сервера Windows 2008 R2
• серверная ОС работает в VMware 4.1 VM с 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 в этом случае? Являются ли эти цифры "неправильными" в некотором смысле? Могут ли они быть улучшены путем настройки некоторых параметров?
• Какие дополнительные шаги следует предпринять, чтобы точно определить причины замедления?