Ajuste del rendimiento en Informatica: tutorial completo

⚡ Resumen inteligente

La optimización del rendimiento en Informatica elimina el enlace más lento de una sesión, capa por capa, trabajando desde el destino hacia atrás a través del origen, el mapa.ping, la sesión y finalmente el sistema operativo.

🎯 Pedido fijo: Informatica recomienda buscar cuellos de botella como objetivo, luego como origen y finalmente como mapa.ping, luego sesión, luego sistema.
🧵 Las estadísticas de los hilos lo dicen todo: El hilo más activo de lector, transformación y escritor nombra la capa que necesita trabajo.
🚿 Filtrar con anticipación: Las filas descartadas en el calificador de origen nunca entran en la canalización, por lo que no suponen ningún coste posterior.
🗄️ Enviar el trabajo a la base de datos: Las operaciones de unión, ordenación y filtrado suelen ser más rápidas en SQL que en una transformación.
🧊 Disciplina de caché: Menos puertos y menos columnas de búsqueda significan cachés más pequeñas y menos paginación de disco.
⚙️ La configuración de la sesión es importante: El tamaño del búfer DTM, el tamaño del bloque del búfer, el intervalo de confirmación y la optimización de la inserción se ajustan después del mapeo.ping esta limpio.

Descubre más

¿Qué es la optimización del rendimiento en Informatica?

La optimización del rendimiento en Informatica consiste en identificar el componente que limita la velocidad de una sesión, eliminar dicho límite y repetir el proceso con el componente que resulte más lento. La velocidad de una sesión depende exclusivamente de su capa más lenta, por lo que optimizar una transformación que nunca fue el problema no produce ninguna mejora apreciable.

Informatica identifica cinco puntos donde puede producirse un cuello de botella y recomienda revisarlos en un orden fijo.

Pedido	Capa	Causa típica
1	Target	Escrituras lentas, intervalos de puntos de control pequeños, tamaños de paquetes de red de base de datos pequeños
2	Fuente	Consulta lenta, índices faltantes, lectura de columnas innecesarias
3	Mapeo	Transformaciones costosas o mal ubicadas, cachés de gran tamaño.
4	Sesión	Buffer memoria, intervalo de confirmación, particionamiento, tipo de carga
5	Sistema	Saturación de CPU, esperas de E/S, paginación en la máquina del Servicio de Integración.

El orden es deliberado. Un objetivo que no puede absorber filas lo suficientemente rápido hará que cada capa anterior parezca lenta, por lo que se comprueba primero. El método completo está documentado en el Guía de optimización del rendimiento de PowerCenter.

Cómo identificar cuellos de botella en el rendimiento

Adivinar qué capa es la más lenta consume más tiempo que medirla. Cuatro técnicas abarcan las cinco capas mencionadas anteriormente.

Ejecuta una sesión de prueba. Configurar una copia de la durante toda la sesión. Para escribir en un archivo plano, si la sesión se acelera notablemente, el cuello de botella se encuentra en el archivo plano. El método inverso, que consiste en leer desde un archivo plano, permite identificar el cuello de botella en el origen.
Analizar las estadísticas de los hilos. El Administrador de Transformación de Datos ejecuta un hilo de lectura, uno o más hilos de transformación y un hilo de escritura. El hilo con el mayor tiempo de actividad en el registro de sesión apunta directamente a la capa en la que trabajar: lector para la fuente, transformación para el mapa.ping, escritor para el objetivo.
Analizar los detalles de rendimiento. Habilite la recopilación de datos de rendimiento en la sesión y lea los contadores. Un alto número de filas con errores o una gran cantidad de filas en una caché de búsqueda indican un mapa.ping problema en lugar de un problema de base de datos.
Supervise el sistema. Operaherramientas del sistema que muestran el uso de la CPU, las esperas de E/S y la paginación, junto con la Monitor de flujo de trabajo Las vistas de recursos revelan que la máquina simplemente está fuera de capacidad.

Una vez que se conoce la capa responsable, vale la pena aplicar los consejos a nivel de transformación en las siguientes secciones. Las secciones están organizadas en orden de canalización, desde el punto donde los datos ingresan a la mapaping hasta el punto en que se agrega.

Transformación de calificador de fuente

Cada fila que el calificador de origen no lee es una fila que ninguna otra transformación tiene que procesar, lo que lo convierte en el lugar más barato de todo el mapa.ping para ahorrar tiempo.

Traiga solo las columnas requeridas de la fuente. La mayoría de las veces no todas las columnas de la tabla de origen son obligatorias, así que traiga sólo los campos obligatorios eliminando las columnas innecesarias.
Evite usar la cláusula ORDER BY dentro del Calificador de fuente Sobrescritura SQL. La cláusula ORDER BY requiere procesamiento adicional y el rendimiento puede mejorarse evitándola.

Transformación de filtro

El filtrado sigue el mismo principio un paso más adelante en la cadena: descartar las filas no deseadas en el punto más temprano en el que el mapaping tiene suficiente información para identificarlos.

Usar transformación de filtro lo antes posible dentro del mapapingSi los datos no deseados se pueden descartar al principio del mapaping, aumentaría el rendimiento.
Utilice el calificador de origen para filtrar los datos. También puede usar la anulación SQL del calificador de origen para filtrar los registros, en lugar de usar la transformación de filtro.

Transformación Joiner

Unirse es la primera operación realmente costosa en un mapa típico.ping, porque la fuente maestra debe almacenarse en caché antes de que las filas de detalle puedan compararse con ella.

Siempre que sea posible, es preferible realizar las uniones en la base de datos, ya que las uniones en la base de datos son más rápidas que las uniones creadas en Informatica. transformación de carpintero.
Ordene los datos antes de unirlos si es posible, ya que disminuye la E/S del disco realizada durante la unión.
Establezca como tabla maestra la tabla con menor número de filas.

El tercer punto es el que con mayor frecuencia se pasa por alto. El Servicio de Integración almacena en caché la fuente maestra, por lo que designar la tabla más pequeña como maestra mantiene esa caché reducida.

Transformación de búsqueda

Una búsqueda puede consultar la base de datos una vez por fila o crear una caché en memoria, y ambas opciones favorecen una fuente de búsqueda más pequeña y mejor indexada.

Cree un índice para la columna en un tabla de búsqueda que se utiliza en la condición de búsqueda. Dado que se consultará la tabla de búsqueda para encontrar los datos coincidentes, agregar un índice mejoraría el rendimiento.
Si es posible, en lugar de utilizar la transformación de búsqueda, utilice unirse en la base de datos. A medida que las uniones a bases de datos sean más rápidas, aumentará el rendimiento.
Elimine las columnas innecesarias de la tabla de búsqueda y conserve solo las columnas requeridas. Esto reducirá la sobrecarga de buscar columnas adicionales de la base de datos.

Transformación de agregador

An Aggregator Almacena datos en caché mientras agrupa filas, por lo que cualquier cosa que reduzca el volumen de datos que recibe reduce la caché que necesita.

Filtra los datos antes de agregarlos. Si estás utilizando la transformación de filtro en el mapapingLuego, filtre los datos antes de usar el agregador, ya que esto reducirá la operación de agregación innecesaria.
Limite el número de puertos utilizados en la transformación de agregación. Esto reducirá el volumen de datos que la transformación de agregación almacena en la caché.

Ajuste a nivel de sesión en Informatica

Cuando el mapaping El sistema en sí es eficiente; las mejoras restantes provienen de las propiedades de la sesión. Conviene modificar estos ajustes uno a uno, realizando una prueba cronometrada después de cada cambio, ya que varios de ellos implican sacrificar memoria en aras de la velocidad.

Configuración	Lo que controla	Cuándo cambiarlo
Tamaño del búfer DTM	Memoria total que el Servicio de Integración asigna para los bloques de datos de origen y destino.	Aumenta cuando la sesión maneja muchas particiones, orígenes o destinos.
Buffer tamaño de bloque	Tamaño de un bloque de memoria individual	Aumentar para filas inusualmente grandes; disminuir cuando la memoria física es limitada.
Intervalo de compromiso	¿Cuántas filas se escriben antes de que se emita una confirmación?	Genera este error cuando el hilo de escritura dedique su tiempo a esperar puntos de control de la base de datos.
Optimización de empuje	¿Qué parte del mapa?ping La lógica se convierte en SQL y es ejecutada por la base de datos.	Úselo cuando el origen y el destino se encuentren en la misma base de datos potente.

Buffer La memoria se basa en un cálculo documentado en lugar de conjeturas. El Servicio de Integración asigna al menos dos bloques para cada partición de origen y destino, por lo que el número de bloques del búfer de sesión es (orígenes totales + destinos totales) multiplicado por dos, y el tamaño del búfer DTM es ese número de bloques multiplicado por el tamaño del bloque del búfer y dividido por 0.9.

La optimización pushdown merece una advertencia. Solo ayuda cuando la base de datos es realmente más rápida que la máquina del Integration Service y la lógica de transformación se puede expresar en SQLLa lógica que no se puede traducir permanece en la sesión, por lo que la mejora suele ser menor de lo esperado. Mida antes y después en lugar de habilitarlo por defecto.

Preguntas Frecuentes

El particionamiento resulta útil cuando la máquina del Servicio de Integración dispone de CPU libre y el origen y el destino pueden gestionar conexiones paralelas. En una máquina saturada o con un destino de un solo hilo, las particiones adicionales generan sobrecarga sin acortar el tiempo de ejecución.

Configure el índice y la caché de datos con un tamaño suficiente para almacenar toda la fuente de búsqueda; de lo contrario, las páginas del Servicio de Integración se guardarán en el disco. Los registros de sesión informan del tamaño de caché necesario, así que ejecute el proceso una vez con dimensionamiento automático y lea el valor.

Cada inserción también mantiene todos los índices y restricciones en el destino, y ese costo aumenta con el tamaño de la tabla. Las estadísticas obsoletas de la base de datos empeoran la situación. El hilo de escritura se convierte entonces en el hilo más ocupado, lo que constituye la señal clásica de un cuello de botella en el destino.

Sí, porque la transformación puede liberar cada grupo tan pronto como finaliza, en lugar de almacenar todo en caché. Las filas entrantes deben estar ordenadas previamente por los puertos de agrupación, y la sesión falla si no lo están.

Para una carga grande solo de insertos, deje caerping Generalmente, es más rápido crear primero los índices y las restricciones y reconstruirlos después. Los comandos SQL previos y posteriores a la sesión, aplicados a las propiedades de la sesión, son el lugar habitual para automatizar ambos pasos.

El modo masivo omite gran parte del registro de la base de datos y carga más rápido, pero impide la recuperación y no funciona con todos los destinos ni con todas las estrategias de actualización. El modo normal escribe a través de la ruta de registro habitual y mantiene la posibilidad de recuperación.

Los modelos entrenados con datos históricos de tiempos de ejecución detectan una sesión que se ha desviado de su duración normal mucho antes de que nadie lo note, y también identifican fallos relacionados con el clúster. Señalan la ejecución que sufrió el cambio; la capa responsable aún debe confirmarse mediante estadísticas de subprocesos.

Puede reescribir una consulta, sugerir posibles índices y explicar un plan de ejecución pegado en el editor. No puede ver el repositorio ni el registro de sesión, por lo que cualquier reescritura debe validarse con respecto al plan real y el número de filas.