Recuento de threads óptimo

La ejecución de un proceso en segundo plano en varios threads siempre es más rápida que si se ejecuta en un solo thread. La cuestión consiste en determinar el número de threads que resulta óptimo para cada proceso.

Nota: una buena norma general consiste en tener un thread por cada 100 MHz de CPU disponible en el servidor de aplicación. Por ejemplo, si tiene cuatro procesadores disponibles de 450 MHz en el servidor de aplicación, puede comenzar con 18 threads para iniciar las pruebas: (450*4)/100=18.

Esta es una norma general porque cada proceso es distinto y depende de los datos de la base de datos. Además, la configuración de hardware (es decir, el número de procesadores, la velocidad de los discos duros, la velocidad de la red entre el servidor de base de datos y el servidor de aplicación) influye en el número óptimo de threads. Siga estas directrices para determinar el número óptimo de threads para cada proceso en segundo plano:

  • Ejecute el proceso en segundo plano utilizando el número de threads indicado por la norma general (descrita anteriormente). Durante esta ejecución, supervise el porcentaje de utilización del servidor de aplicación, el servidor de base de datos y el tráfico de red.

  • Si descubre que el servidor de base de datos indica un uso del 100%, pero el servidor de aplicación no lo indica, probablemente esté ocurriendo una de las situaciones siguientes:

    • Es posible que haya una sentencia SQL problemática que se está ejecutando durante el proceso. Debe capturar un rastreo de la base de datos para identificar la sentencia SQL que causa el problema.

    • También es posible que la frecuencia de validación sea demasiado grande. Este es un parámetro que se proporciona para cada proceso en segundo plano. Si es demasiado grande, las colas de retención de la base de datos pueden comenzar a cambiar. Consulte Parámetros proporcionados para procesos en segundo plano para obtener más información sobre este parámetro.

  • Es normal que encuentre que el servidor de aplicación indique un uso del 100% pero el servidor de base de datos no. Esto es normal porque, en general, todos los procesos están ligados a la CPU y no a la E/S. En este punto, debe reducir el número de threads hasta obtener un uso del servidor de aplicación justo por debajo del 100%. Este será el número óptimo de threads necesario para este proceso en segundo plano.

  • Si detecta que el servidor de aplicación no alcanza el 100% de utilización, debe aumentar el número de threads hasta obtener un uso del servidor de aplicación justo por debajo del 100%. Recuerde que el servidor de aplicación debe alcanzar un uso del 100% antes de que el servidor de base de datos alcance un uso del 100%. Si se demuestra que esto no es cierto, puede que haya algún problema con una sentencia SQL y deba capturar un rastreo de SQL, para determinar cuál es la causa del problema.

Otra manera de obtener resultados similares consiste en comenzar con un pequeño número de threads y aumentar el número de threads hasta que se maximice la capacidad de proceso. La definición de "capacidad de proceso" puede variar para cada proceso, pero se puede generalizar como un recuento sencillo de los registros procesados en el árbol de ejecución de lotes. Por ejemplo, en el proceso en segundo plano de facturación de Oracle Utilities Customer Care and Billing, la capacidad de proceso es el número de facturas procesadas por minuto. Si decide utilizar este método, se recomienda trazar una curva de la capacidad de proceso frente al número de threads. El gráfico debe representar una curva que al principio es pronunciada pero que después se va aplanando, a medida que se añaden más threads. Finalmente, al añadirse más threads se conseguirá que la capacidad de proceso se reduzca. Con este tipo de análisis se puede determinar el número óptimo de threads que se ejecutarán para cualquier proceso determinado.