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

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

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

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

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

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

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

Наблюдения:

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

БЛОК LOCK_HEADER

    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, интерпретируемого в этом случае? Находятся эти числа "неправильно" в некотором смысле? Они могут быть улучшены некоторой настройкой параметра?
• Какие дополнительные шаги должны быть сделаны для точного определения то, что вызывает замедление?