Firebird diminui a velocidade enquanto os recursos estão disponíveis

Question

Eu tenho um problema de lentidão estranho com um banco de dados Firebird. Durante o uso diário do banco de dados, os clientes experimentam lentidão significativa enquanto o sistema ainda tem muitos recursos disponíveis. Alguns informações sobre o meio ambiente:

• servidor Firebird 2.5.2 de 64 bits em execução no modo SuperServer
• o banco de dados está sendo executado em um sistema operacional de servidor Windows 2008 R2 de 64 bits
• o sistema operacional do servidor está sendo executado em uma VM do VMware 4.1 com 4 núcleos de CPU e 16 GB de RAM
• o tamanho do banco de dados é de cerca de 37 GB e o número de concorrentes conexões para o banco de dados é de cerca de 150.

Enquanto observa as lentidões:

• o uso da CPU na máquina está entre 40-60% sem picos mais altos e a carga é bem distribuída entre todos os 4 núcleos
• o uso de memória do servidor é de cerca de 4-6 GB e o restante do memória é usada como cache do sistema operacional
• a largura da fila de disco quase nunca ultrapassa 0,3 com latência de cerca de 2-5 ms
• quase não há atividade de rede no servidor.

Ainda assim, a lentidão parece estar ligada à carga geral no servidor. Durante a noite, quando nenhum usuário está conectado ao banco de dados / sem trabalhos em segundo plano estão executando uma consulta de teste usada para referência executa em 4-5 segundos, enquanto durante o dia, quando todos os os usuários estão conectados ao banco de dados executando a mesma consulta de referência requer 60 segundos para terminar. Deve ser acrescentado que o desaceleração é de natureza geral, não há consultas específicas que são mais lento enquanto o servidor está sob carga, tudo fica mais lento dentro o banco de dados específico do Firebird. O servidor tem outros bancos de dados com número muito baixo de transações executadas diariamente e esses outros bancos de dados não mostram sinais de lentidão. Eu até criei uma cópia do live banco de dados experimentando lentidão e executou a mesma consulta contra tanto o original como o banco de dados duplicado - o original execute a consulta lenta e rapidamente duplicada. A única diferença entre o original e a duplicata que eu conheço é o número de usuários conectados / transações simultâneas.

Como não encontrei razões evidentes de todos estes no SO disponível recursos, então eu tentei buscar estatísticas do Firebird.

As observações:

• nos horários de pico, o banco de dados tem 30 a 40 transações em execução paralelamente de acordo com mon $ instruções (onde mon $ state == 1, que de acordo com os arquivos significa que as transações estão em execução ou estão à espera de um bloqueio)
• fb_lock_print exibe o seguinte sobre o banco de dados:

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

Aqui, observei que o campo "rejeita" representa ~ 14% de "enqs" campo, mas infelizmente eu não sei o significado exato destes valores. Eu acho que cerca de 14% dos pedidos de bloqueio são rejeitados por algum razão, mas posso estar completamente errado.

Então as perguntas:

• Como a saída de fb_lock_print deve ser interpretada neste caso? Está esses números "errados" em algum sentido? Eles podem ser melhorados por alguns ajuste de parâmetro?
• Quais etapas adicionais devem ser tomadas para identificar o que causa a lentidão?