Recuento Óptimo de Subprocesos

Ejecutar un proceso de segundo plano en múltiples subprocesos es casi siempre más rápido que ejecutarlo en un subproceso único. La clave es determinar el número de subprocesos que es óptimo para cada proceso.

Nota: Una buena regla general es tener un subproceso por cada 100 MHz de CPU de servidor de aplicación disponible. Por ejemplo, si tiene cuatro procesadores de 450 MHz disponibles en el servidor de aplicación, puede comenzar con 18 subprocesos para iniciar la prueba: (450 * 4) / 100 = 18.

Ésta es una regla general porque cada proceso es diferente 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 las unidades de disco y la velocidad de la red entre el servidor de base de datos y el servidor de aplicación) afecta al número óptimo de subprocesos. Siga estas pautas para determinar el número óptimo de subprocesos para cada proceso de segundo plano:

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

  • Si encuentra que el servidor de base de datos alcanzó 100% de utilización, pero no así el servidor de aplicación, probablemente ocurra una de las siguientes situaciones:

    • Podría haber una sentencia SQL problemática ejecutándose durante el proceso. Debe capturar un rastreo de base de datos para identificar la SQL con problemas.

    • También es posible que la frecuencia de validación sea demasiado extensa. La frecuencia de validación es un parámetro suministrado a cada proceso de segundo plano. Si es demasiado extenso, las colas de retención de la base de datos pueden comenzar a intercambiarse. Consulte Parámetros Suministrados a Procesos de Segundo Plano para obtener más información acerca de este parámetro.

  • Es normal si encuentra que el servidor de aplicación alcanzó 100% de utilización, pero no así el servidor de base de datos. Esto es normal porque, en general, todos los procesos están ligados a la CPU y no a IO. En este punto, debe disminuir el número de subprocesos hasta alcanzar justo bajo 100% de utilización del servidor de aplicación. Éste será el número óptimo de subprocesos para este proceso de segundo plano.

  • Si observa que el servidor de aplicación no alcanzó el 100% de utilización, debe aumentar el número de subprocesos hasta que el servidor de aplicación alcance un nivel justo por debajo del 100% de utilización. Recuerde, el servidor de aplicación debe alcanzar 100% de utilización antes de que el servidor de base de datos alcance 100% de utilización. Si se comprueba que esto no es verdadero, algo probablemente está fallando con una sentencia SQL y debe capturar un SQL trace para determinar el responsable.

Otra forma de lograr resultados similares es comenzar con un número pequeño de subprocesos y aumentarlo hasta haber maximizado el rendimiento. La definición de "rendimiento" puede diferir para cada proceso, pero se puede generalizar como un simple recuento de registros procesados en el árbol de ejecución de lote. Por ejemplo, en el proceso de segundo plano de Facturación en Oracle Utilities Customer Care and Billing, el rendimiento es el número de facturas procesadas por minuto. Si opta por usar este método, recomendamos que grafique la curva de rendimiento contra el número de subprocesos. El gráfico debe desplegar una curva que al principio es empinada, pero luego queda plana en la medida que se agregan más subprocesos. A la larga, agregar más subprocesos hará que el rendimiento disminuya. A través de este tipo de análisis, puede determinar el número óptimo de subprocesos a ejecutar para algún proceso dado.