Servidor de informes de Power BI y SSIS

Un usuario Pregunto ✅

jbarta

Instalé el servidor de informes de Power BI en una máquina virtual que ejecuta Windows Server 2012 R2. Es un servidor en el que tenía un paquete SSIS ejecutándose para convertir datos de una base de datos de producción. Antes de la instalación, el paquete se ejecutó en 15 a 18 minutos. El día después de la instalación, el paquete comenzó a ejecutarse entre 30 y 35 minutos, casi el doble. No estoy seguro de que el servidor de informes de Power BI sea el culpable de la diferencia en el tiempo de ejecución del paquete. Hice algunas pruebas durante el fin de semana, apagué el servicio del servidor de informes y desconecté las dos bases de datos. Eso no mejoró el tiempo de ejecución. La instalación del servidor de informes de Power BI es nueva y no contiene informes de SSRS ni informes de Power BI Desktop. Debido a las pruebas con el servicio apagado y las bases de datos fuera de línea, creo que el servidor de informes de Power BI no tiene la culpa, pero quería ver si alguien en este foro piensa diferente o ha experimentado lo mismo. Cualquier idea sería útil. ¡Gracias!

stpnet

En respuesta a jbarta

Donde empezar…

Lo que pasa con SSIS es que cuando lo ejecuta, tomará una GRAN cantidad de memoria. Cuánto depende de cuántos paquetes ejecute en paralelo, cada paquete obtiene x procesos (10 por defecto). Cada proceso toma un trozo de memoria. A medida que se pasa cada proceso, una tarea de SSIS para ejecutarlo requerirá más memoria según lo requiera. Si un proceso encuentra un flujo de datos, comenzará a crear búferes de datos (10 de forma predeterminada de nuevo) cada búfer está diseñado para contener alrededor de 10 000 filas de datos, por lo que el tamaño de un búfer depende principalmente del ancho (tamaño de bytes) de las filas de datos que están siendo «movidos». Cualquier columna NTEXT, IMAGE o BLOB hace que los búferes exploten bastante rápido. Todo esto afecta la cantidad de «memoria» que SSIS intentará reclamar.

SSIS no funciona bien con otros sistemas. Quiere TODO el recuerdo muchas gracias. Por lo tanto, ejecutarlo junto con SQL Server, SSAS o SSRS es obviamente «interesante», ya que TODOS quieren TODA la memoria.

Hay 2 o 3 cosas que podrían haber pasado.

La primera es que PBI-SSRS obviamente consume una gran cantidad de memoria. Cerrar el servicio e intentar ejecutar SSIS probablemente habrá liberado esa memoria para que SSIS pueda usarla. Entonces, si eso no hace una diferencia apreciable, es poco probable que sea su problema. Debería poder saber qué tan lleno está su espacio de memoria usando el administrador de tareas, si la memoria libre es excepcionalmente baja, entonces es posible que SSIS se esté comportando mal debido a la falta de memoria.

La segunda es que su PBI-SSRS ha estado ejecutando algunas consultas en el servicio MSSQL que bien puede estar consumiendo una gran cantidad de memoria en el grupo de búfer de SQL Server o algo así. SQL Server puede hacer esto y conservar la memoria en caso de que la necesite para otra cosa. SQL Server es así (necesitado y de alto mantenimiento), por lo que podría ser una idea reiniciar SQL Server y probar su SSIS en ese momento. Puede ajustar la configuración de memoria para SQL Server para evitar que tome demasiada memoria y para que suelte memoria cuando el servidor de Windows subyacente esté bajo presión de memoria.

Lo último (que me viene a la mente) es que SSISDB (catálogo SSSI) no es terriblemente eficiente si tiene muchas versiones de paquetes y muchos datos registrados. Si implementó una nueva versión de su paquete, esa podría ser la causa (la instalación de PBI-SSRS podría ser solo una coincidencia), esta disminución del rendimiento no es gradual. ¡Está bien, está bien, está bien, y de repente está corriendo como un perezoso muerto!

Sugeriría monitorear el uso de la CPU y el uso de la memoria mientras se ejecuta el paquete. Si la memoria no está abarrotada, debería ver que la CPU funciona bien mientras se ejecuta el paquete SSIS. Verá actividad para SSIS y también para SQL (el catálogo de SSIS registrará cosas en su SSISDB y moverá datos a una base de datos para que SQL haga una buena parte del trabajo)

Si la CPU está muy detenida, comience con períodos en los que nada parece estar haciendo nada, esto comúnmente sugiere que su SSISDB puede ser el problema. (también puede significar que SQL tiene dificultades para almacenar sus datos, si la base de datos de destino se está quedando sin espacio, es posible que vea perf probelsm en SSIS). impacto.

si está interesado en ver cómo se está desempeñando su ssis, lea esto

https://docs.microsoft.com/en-us/sql/integration-services/performance/monitor-running-packages-and-o…

https://technet.microsoft.com/en-us/library/ms141687%28v=sql.90%29.aspx?f=255&MSPPError=-2147217396

Desafortunadamente no hay respuestas «cortas».

Buena suerte

Hola @jbarta,

Este debería ser un problema de rendimiento de SSIS. Puede ajustar el rendimiento siguiendo: https://technet.microsoft.com/library/Cc966529. Si aún tiene problemas, publique un hilo en el foro de SSIS.

Atentamente,
qiuyun yu

jbarta

En respuesta a v-qiuyu-msft

¡Gracias por su respuesta!

He realizado algunos ajustes en el paquete SSIS y ha ayudado un poco. Pero todavía no funciona como lo hizo los días previos a la instalación de Power BI Report Server. Tengo a mi equipo de TI tratando de ver si algunos de los recursos para el servidor se han asignado a otro lugar en el mismo período de tiempo. Pero para que se ejecutara en 15 minutos un día y luego en 30 minutos al día siguiente después de la instalación del servidor de Power BI Report, me hizo sospechar que la instalación estaba causando la ralentización. Como mencioné anteriormente, apagué el servicio Power BI Report Server y las bases de datos estaban fuera de línea y no mejoró el tiempo de ejecución del paquete. Supuse que si hacía eso y ejecutaba el paquete, me diría que Power BI Report Server no es el problema. Entonces, ¿puede decirme si apagué el servicio y desconecté las bases de datos del servidor de informes de Power BI y no mejoró el tiempo de ejecución del paquete, en su opinión, eso elimina el problema del servidor de informes de Power BI? Solo quiero asegurarme de haber tomado las medidas adecuadas para eliminar y determinar eso.

En respuesta a jbarta

Hola @jbarta,

Personalmente, según su prueba, el servidor de informes de Power BI no debería ser el problema.

Para solucionar mejor el problema, le sugiero que obtenga ayuda de los expertos de SSIS como sugerí antes de que pueda publicar un hilo en el foro de SSIS.

Atentamente,
qiuyun yu

jbarta

En respuesta a v-qiuyu-msft

Gracias por su respuesta.

stpnet

En respuesta a jbarta

Donde empezar…

Lo que pasa con SSIS es que cuando lo ejecuta, tomará una GRAN cantidad de memoria. Cuánto depende de cuántos paquetes ejecute en paralelo, cada paquete obtiene x procesos (10 por defecto). Cada proceso toma un trozo de memoria. A medida que se pasa cada proceso, una tarea de SSIS para ejecutarlo requerirá más memoria según lo requiera. Si un proceso encuentra un flujo de datos, comenzará a crear búferes de datos (10 de forma predeterminada de nuevo) cada búfer está diseñado para contener alrededor de 10 000 filas de datos, por lo que el tamaño de un búfer depende principalmente del ancho (tamaño de bytes) de las filas de datos que están siendo «movidos». Cualquier columna NTEXT, IMAGE o BLOB hace que los búferes exploten bastante rápido. Todo esto afecta la cantidad de «memoria» que SSIS intentará reclamar.

SSIS no funciona bien con otros sistemas. Quiere TODO el recuerdo muchas gracias. Por lo tanto, ejecutarlo junto con SQL Server, SSAS o SSRS es obviamente «interesante», ya que TODOS quieren TODA la memoria.

Hay 2 o 3 cosas que podrían haber pasado.

La primera es que PBI-SSRS obviamente consume una gran cantidad de memoria. Cerrar el servicio e intentar ejecutar SSIS probablemente habrá liberado esa memoria para que SSIS pueda usarla. Entonces, si eso no hace una diferencia apreciable, es poco probable que sea su problema. Debería poder saber qué tan lleno está su espacio de memoria usando el administrador de tareas, si la memoria libre es excepcionalmente baja, entonces es posible que SSIS se esté comportando mal debido a la falta de memoria.

La segunda es que su PBI-SSRS ha estado ejecutando algunas consultas en el servicio MSSQL que bien puede estar consumiendo una gran cantidad de memoria en el grupo de búfer de SQL Server o algo así. SQL Server puede hacer esto y conservar la memoria en caso de que la necesite para otra cosa. SQL Server es así (necesitado y de alto mantenimiento), por lo que podría ser una idea reiniciar SQL Server y probar su SSIS en ese momento. Puede ajustar la configuración de memoria para SQL Server para evitar que tome demasiado y para que suelte memoria cuando el servidor de Windows subyacente está bajo presión de la memoria.

Lo último (que me viene a la mente) es que SSISDB (catálogo SSSI) no es terriblemente eficiente si tiene muchas versiones de paquetes y muchos datos registrados. Si implementó una nueva versión de su paquete, esa podría ser la causa (la instalación de PBI-SSRS podría ser solo una coincidencia), esta disminución del rendimiento no es gradual. ¡Está bien, está bien, está bien, y de repente está corriendo como un perezoso muerto!

Sugeriría monitorear el uso de la CPU y el uso de la memoria mientras se ejecuta el paquete. Si la memoria no está abarrotada, debería ver que la CPU funciona bien mientras se ejecuta el paquete SSIS. Verá actividad para SSIS y también para SQL (el catálogo de SSIS registrará cosas en su SSISDB y moverá datos a una base de datos para que SQL haga una buena parte del trabajo)

Si la CPU está muy detenida, comience con períodos en los que nada parece estar haciendo nada, esto comúnmente sugiere que su SSISDB puede ser el problema. (también puede significar que SQL tiene dificultades para almacenar sus datos, si la base de datos de destino se está quedando sin espacio, es posible que vea perf probelsm en SSIS). impacto.

si está interesado en ver cómo se está desempeñando su ssis, lea esto

https://docs.microsoft.com/en-us/sql/integration-services/performance/monitor-running-packages-and-o…

https://technet.microsoft.com/en-us/library/ms141687%28v=sql.90%29.aspx?f=255&MSPPError=-2147217396

Desafortunadamente no hay respuestas «cortas».

Buena suerte

jbarta

En respuesta a stpnet

Gracias por toda esa gran información. Realmente me ayudó a darme cuenta de que necesito presionar más a mi equipo de TI para ver qué cambió en el servidor en cuanto a recursos durante el tiempo de instalación del servidor de informes de Power BI. Pero gracias por toda esa información.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *