Contagem de Thread Ideal

A execução de um processo em segundo plano em vários threads é sempre mais rápida do que a execução em um único thread. A dica é determinar o número de threads ideais de cada processo.

Observação: A regra geral ideal é haver um thread para cada 100 MHz da CPU do servidor de aplicativo. Por exemplo, se você tiver quatro processadores de 450 MHz disponíveis no servidor de aplicativo, será possível começar com 18 threads para iniciar o teste: (450 * 4)/100 = 18.

Essa é uma regra geral porque cada processo é diferente e depende dos dados em seu banco de dados. Além disso, sua configuração de hardware (ou seja, o número de processadores, a velocidade das unidades de disco e da rede entre o servidor do banco de dados e o servidor de aplicativo) tem um impacto no número ideal de threads. Siga estas instruções para determinar o número ideal de threads de cada processo em segundo plano:

  • Execute o processo em segundo plano usando o número de threads determinado pela regra geral (descrita acima). Durante essa execução, monitore o percentual de utilização de seu servidor de aplicativo, servidor de banco de dados e tráfego da rede.

  • Se o servidor de banco de dados tiver utilização com 100%, mas seu servidor de aplicativo não tiver, um dos casos a seguir poderá estar ocorrendo:

    • Há uma instrução SQL com problema em execução durante o processo. Você deve capturar o rastreio de banco de dados para identificar a SQL com problema.

    • Pode ser que sua frequência de commit seja muito grande. A frequência de commit é um parâmetro fornecido para cada processo em segundo plano. Se ela for muito grande, as filas de suspensão do banco de dados poderão iniciar a troca. Para obter mais informações sobre esse parâmetro, consulte Parâmetros Fornecidos a Processos em Segundo Plano.

  • Será normal se você constatar que seu servidor de aplicativo tiver utilização de 100%, mas o servidor de banco de dados, não. Isso é normal porque, de modo geral, todos os processos são associados à CPU e não à E/S. Nesse ponto, você deve diminuir o número de threads até que utilização do servidor de aplicativo fique sempre abaixo de 100%. E esse será o número de threads necessário para esse processo em segundo plano.

  • Se você constatar que seu servidor de aplicativo não alcançou 100% de utilização, aumente o número de threads até obter quase 100% de utilização no servidor de aplicativo. E lembre-se: o servidor de aplicativo deve obter utilização de 100% antes de o servidor de banco de dados tenha utilização de 100%. Se isso não ocorrer, alguma coisa poderá estar errada com a instrução SQL, e você deverá capturar um rastreio de SQL para determinar a causa.

Outra maneira de obter resultados semelhantes é começar com um número pequeno de threads e aumentar a quantidade até o rendimento total. A definição de "rendimento" pode ser diferente para cada processo, mas pode ser generalizada como uma simples contagem dos registros processados na execução em batch. Por exemplo, no processo em segundo plano do Faturamento no Oracle Utilities Customer Care and Billing, o rendimento é o número de faturas processadas por minuto. Se você usar esse método, recomendamos criar em gráfico uma curva de rendimento em relação ao número de threads. O gráfico deve exibir uma curva ascendente no início, mas nivelada em seguida, quando mais threads forem adicionados. No final, a adição de mais threads fará com que o rendimento diminua. Por meio desse tipo de análise, você pode determinar o número ideal de threads a ser executado para qualquer processo determinado.