Solución de problemas de rendimiento de la actividad de copia

  • Artículo

SE APLICA A: Azure Data Factory Azure Synapse Analytics

Sugerencia

Pruebe Data Factory en Microsoft Fabric, una solución de análisis todo en uno para empresas. Microsoft Fabric abarca todo, desde el movimiento de datos hasta la ciencia de datos, el análisis en tiempo real, la inteligencia empresarial y los informes. Obtenga información sobre cómo iniciar una nueva evaluación gratuita.

En este artículo se describe cómo solucionar problemas de rendimiento de la actividad de copia en Azure Data Factory.

Después de ejecutar una actividad de copia, puede recopilar el resultado de la ejecución y estadísticas de rendimiento en la vista de supervisión de la actividad de copia. A continuación se muestra un ejemplo.

Monitor copy activity run details

Sugerencias de optimización del rendimiento

En algunos escenarios, cuando se ejecuta una actividad de copia, aparece el mensaje "Sugerencias para la optimización del rendimiento" en la parte superior, como se muestra en el ejemplo anterior. Las sugerencias señalan el cuello de botella identificado por el servicio para la ejecución específica de la copia, junto con recomendaciones sobre cómo aumentar su rendimiento. Intente llevar a cabo el cambio sugerido y ejecute la copia de nuevo.

Como referencia, actualmente las sugerencias de optimización del rendimiento proporcionan recomendaciones para los siguientes casos:

Category Sugerencias de optimización del rendimiento
Específica del almacén de datos Carga de datos en Azure Synpase Analytics: se recomienda usar PolyBase o la instrucción COPY si no se usa.
  Copia de datos de o a Azure SQL Database: cuando la DTU tiene un uso elevado, se recomienda actualizar a un nivel superior.
  Copia de datos de o a Azure Cosmos DB: cuando la RU tiene un uso elevado, se recomienda actualizar a una RU mayor.
Copia de datos de una tabla de SAP: al copiar una gran cantidad de datos, se recomienda aprovechar la opción de partición del conector SAP para permitir la carga paralela y aumentar el número máximo de particiones.
  Ingesta de datos de Amazon Redshift: se recomienda el uso de UNLOAD si no se usa.
Limitación del almacén de datos Si el almacén de datos limita un número de operaciones de lectura o escritura durante la copia, se recomienda realizar una comprobación y aumentar la tasa de solicitudes permitida para el almacén de datos o reducir la carga de trabajo simultánea.
Tiempo de ejecución de integración Si usa un entorno de ejecución de integración (IR) autohospedado y la actividad de copia espera mucho tiempo en la cola hasta que el IR tiene disponible un recurso para la ejecución, se recomienda escalar horizontal o verticalmente el entorno de ejecución de integración.
  Si usa una instancia de Azure Integration Runtime que se encuentra en una región no óptima, lo que da lugar a una lectura y escritura lentas, se recomienda cambiar la configuración para usar el entorno de ejecución de integración de otra región.
Tolerancia a errores Si configura la tolerancia a errores y la omisión de filas incompatibles provoca un rendimiento lento, se recomienda asegurarse de que los datos de origen y receptor son compatibles.
copia almacenada provisionalmente Si la copia almacenada provisionalmente está configurada pero no resulta útil para el par origen-receptor, se recomienda quitarla.
Reanudación Tenga en cuenta que, cuando la actividad de copia se reanuda desde el último punto de error, pero se cambió la configuración de la unidad de integración de datos (DIU) después de la ejecución original, la nueva configuración de DIU no surte efecto.

Descripción de los detalles de ejecución de la actividad de copia

Los detalles de ejecución y las duraciones en la parte inferior de la vista de supervisión de la actividad de copia describen las fases clave por las que pasa la actividad de copia (consulte el ejemplo al principio de este artículo), lo que resulta especialmente útil para solucionar problemas de rendimiento de la copia. El cuello de botella de la ejecución de copia corresponde a la actividad con la mayor duración. Consulte en la tabla siguiente la definición de cada fase y aprenda a solucionar problemas de la actividad de copia en Azure IR y a solucionar problemas de la actividad de copia en el IR autohospedado con dicha información.

Fase Descripción
Cola Tiempo transcurrido hasta que la actividad de copia se inicia realmente en el entorno de ejecución de integración.
Pre-copy script (Script anterior a la copia) Tiempo transcurrido entre la actividad de copia que comienza en IR y la actividad de copia que finaliza la ejecución del script anterior a la copia en el almacén de datos receptor. Se aplica al configurar el script anterior a la copia para los receptores de base de datos; por ejemplo, al escribir datos en Azure SQL Database, limpiar antes de copiar los datos nuevos.
Transferencia Tiempo transcurrido entre el final del paso anterior y el IR que transfiere todos los datos del origen al receptor.
Tenga en cuenta que los subpasos en transferencia se ejecutan en paralelo y algunas operaciones no se muestran ahora, por ejemplo, para analizar o generar el formato de archivo.

- Time to first byte (Tiempo hasta el primer byte): tiempo transcurrido entre el final del paso anterior y el momento en que la instancia de IR recibe el primer byte del almacén de datos de origen. Se aplica a un origen no basado en archivos.
- Listing source (Lista de orígenes): tiempo empleado en la enumeración de los archivos de origen o las particiones de datos. El último se aplica cuando se configuran las opciones de partición para los orígenes de base de datos; por ejemplo, cuando se copian datos de bases de datos como Oracle, SAP HANA, Teradata, Netezza, etc.
-Reading from source (Lectura desde origen): tiempo empleado en la recuperación de datos desde el almacén de datos de origen.
- Writing to sink (Escritura en el receptor): tiempo empleado en la escritura de datos en el almacén de datos receptor. Tenga en cuenta que algunos conectores no tienen esta métrica en este momento, como Azure AI Search, Azure Data Explorer, Azure Table Storage, Oracle, SQL Server, Common Data Service, Dynamics 365, Dynamics CRM, Salesforce o Salesforce Service Cloud.

Solución de problemas de la actividad de copia en Azure IR

Siga los pasos de optimización del rendimiento para planear y realizar la prueba de rendimiento de su escenario.

Si el rendimiento de la actividad de copia no satisface sus expectativas, quiere solucionar problemas de una única actividad de copia que se ejecuta en Azure Integration Runtime y aparecen sugerencias para optimizar el rendimiento en la vista de supervisión de la copia, aplique la recomendación e inténtelo de nuevo. Si no aparecen estas sugerencias, analice los detalles de ejecución de la actividad de copia, compruebe qué fase presenta la duración más larga y aplique las instrucciones siguientes para aumentar el rendimiento de la copia:

  • La fase de script anterior a la copia muestra una larga duración: esto significa que el script anterior a la copia que se ejecuta en la base de datos receptora tarda mucho tiempo en finalizar. Ajuste la lógica del script anterior a la copia especificado para mejorar el rendimiento. Si necesita más ayuda para mejorar el script, póngase en contacto con el equipo de base de datos.

  • En la fase de transferencia, el tiempo hasta el primer byte muestra una larga duración de trabajo: significa que la consulta de origen tarda mucho tiempo en devolver datos. Compruebe y optimice la consulta o el servidor. Si necesita más ayuda, póngase en contacto con el equipo del almacén de datos.

  • En la fase de transferencia, el listado de orígenes muestra una larga duración de trabajo: significa que la enumeración de los archivos de origen o de las particiones de datos de la base de datos de origen es lenta.

    • Al copiar datos desde el origen basado en archivos, si usa el filtro de comodín en la ruta de acceso de la carpeta o en el nombre de archivo (wildcardFolderPath o wildcardFileName) o usa el filtro de hora de última modificación del archivo (modifiedDatetimeStart o modifiedDatetimeEnd), tenga en cuenta que dicho filtro daría lugar a que la actividad de copia enumerase todos los archivos de la carpeta especificada en el lado de cliente y después aplicase el filtro. Esta enumeración de archivos podría convertirse en el cuello de botella, especialmente cuando solo un pequeño conjunto de archivos cumple la regla del filtro.

      • Compruebe si puede copiar archivos en función del nombre o la ruta de acceso del archivo con particiones de tiempo. De este modo, no se aporta carga alguna a la enumeración del lado de origen.

      • Compruebe si en su lugar puede usar el filtro nativo del almacén de datos, específicamente "prefix" para Amazon S3/Azure Blob Storage/Azure Files y "listAfter/listBefore" para ADLS Gen1. Estos filtros son del lado servidor del almacén de datos y tendrían un rendimiento mucho mejor.

      • Considere la posibilidad de dividir un conjunto de datos de gran tamaño en varios conjuntos de datos más pequeños y permitir que esos trabajos de copia se ejecuten simultáneamente, abordando cada uno de ellos una parte de los datos. Puede hacerlo con Lookup/GetMetadata + ForEach + Copy. Consulte las plantillas de solución de Copia de archivos de varios contenedores o Migración de datos de Amazon S3 a ADLS Gen2 como ejemplo general.

    • Compruebe si el servicio notifica algún error de limitación en el origen o si el almacén de datos muestra un estado de uso elevado. Si es así, reduzca las cargas de trabajo en el almacén de datos o intente ponerse en contacto con el administrador del almacén de datos para aumentar el límite o los recursos disponibles.

    • Use una instancia de Azure IR en la misma región que el almacén de datos de origen o en una región próxima.

  • En la fase de transferencia, la lectura desde el origen muestra una larga duración de trabajo:

    • Adopte el procedimiento recomendado de carga de datos específico del conector si es aplicable. Por ejemplo, al copiar datos desde Amazon Redshift, realice la configuración para que use UNLOAD de Redshift.

    • Compruebe si el servicio notifica algún error de limitación en el origen o si el almacén de datos registra un uso elevado. Si es así, reduzca las cargas de trabajo en el almacén de datos o intente ponerse en contacto con el administrador del almacén de datos para aumentar el límite o los recursos disponibles.

    • Compruebe el patrón del origen y el receptor de la copia:

      • Si el patrón de copia admite más de cuatro unidades de integración de datos (DIU), consulte esta sección para obtener detalles; por lo general, puede intentar aumentar las unidades para obtener un mejor rendimiento.

      • En caso contrario, considere la posibilidad de dividir un conjunto de datos de gran tamaño en varios conjuntos de datos más pequeños y permitir que esos trabajos de copia se ejecuten simultáneamente, abordando cada uno de ellos una parte de los datos. Puede hacerlo con Lookup/GetMetadata + ForEach + Copy. Consulte las plantillas de solución de Copia de archivos de varios contenedores, Migración de datos de Amazon S3 a ADLS Gen2 o Copia masiva con una tabla de control como ejemplo general.

    • Use una instancia de Azure IR en la misma región que el almacén de datos de origen o en una región próxima.

  • En la fase de transferencia, la escritura en el receptor muestra una larga duración de trabajo:

    • Adopte el procedimiento recomendado de carga de datos específico del conector si es aplicable. Por ejemplo, al copiar datos en Azure Synapse Analytics, use PolyBase o la instrucción COPY.

    • Compruebe si el servicio notifica algún error de limitación en el receptor o si el almacén de datos registra un uso elevado. Si es así, reduzca las cargas de trabajo en el almacén de datos o intente ponerse en contacto con el administrador del almacén de datos para aumentar el límite o los recursos disponibles.

    • Compruebe el patrón del origen y el receptor de la copia:

      • Si el patrón de copia admite más de cuatro unidades de integración de datos (DIU), consulte esta sección para obtener detalles; por lo general, puede intentar aumentar las unidades para obtener un mejor rendimiento.

      • De lo contrario, ajuste gradualmente las copias en paralelo; tenga en cuenta que demasiadas copias en paralelo pueden perjudicar el rendimiento.

    • Use una instancia de Azure IR en la misma región que el almacén de datos receptor o en una región próxima.

Solución de problemas de la actividad de copia en IR autohospedado

Siga los pasos de optimización del rendimiento para planear y realizar la prueba de rendimiento de su escenario.

Si el rendimiento de la copia no satisface sus expectativas, quiere solucionar problemas de una única actividad de copia que se ejecuta en Azure Integration Runtime y aparecen sugerencias para optimizar el rendimiento en la vista de supervisión de la copia, aplique la recomendación e inténtelo de nuevo. Si no aparecen estas sugerencias, analice los detalles de ejecución de la actividad de copia, compruebe qué fase presenta la duración más larga y aplique las instrucciones siguientes para aumentar el rendimiento de la copia:

  • La fase de cola muestra una larga duración: significa que la actividad de copia espera mucho tiempo en la cola hasta que la instancia de IR autohospedado tiene el recurso para la ejecución. Compruebe la capacidad y el uso de IR y escale vertical u horizontalmente según la carga de trabajo.

  • En la fase de transferencia, el tiempo hasta el primer byte muestra una larga duración de trabajo: significa que la consulta de origen tarda mucho tiempo en devolver datos. Compruebe y optimice la consulta o el servidor. Si necesita más ayuda, póngase en contacto con el equipo del almacén de datos.

  • En la fase de transferencia, el listado de orígenes muestra una larga duración de trabajo: significa que la enumeración de los archivos de origen o de las particiones de datos de la base de datos de origen es lenta.

    • Compruebe si la máquina del entorno de ejecución de integración autohospedado tiene una latencia baja al conectarse al almacén de datos de origen. Si el origen está en Azure, puede usar esta herramienta para comprobar la latencia de la máquina de IR autohospedado en la región de Azure; es mejor un valor menor.

    • Al copiar datos desde el origen basado en archivos, si usa el filtro de comodín en la ruta de acceso de la carpeta o en el nombre de archivo (wildcardFolderPath o wildcardFileName) o usa el filtro de hora de última modificación del archivo (modifiedDatetimeStart o modifiedDatetimeEnd), tenga en cuenta que dicho filtro daría lugar a que la actividad de copia enumerase todos los archivos de la carpeta especificada en el lado de cliente y después aplicase el filtro. Esta enumeración de archivos podría convertirse en el cuello de botella, especialmente cuando solo un pequeño conjunto de archivos cumple la regla del filtro.

      • Compruebe si puede copiar archivos en función del nombre o la ruta de acceso del archivo con particiones de tiempo. De este modo, no se aporta carga alguna a la enumeración del lado de origen.

      • Compruebe si en su lugar puede usar el filtro nativo del almacén de datos, específicamente "prefix" para Amazon S3/Azure Blob Storage/Azure Files y "listAfter/listBefore" para ADLS Gen1. Estos filtros son del lado servidor del almacén de datos y tendrían un rendimiento mucho mejor.

      • Considere la posibilidad de dividir un conjunto de datos de gran tamaño en varios conjuntos de datos más pequeños y permitir que esos trabajos de copia se ejecuten simultáneamente, abordando cada uno de ellos una parte de los datos. Puede hacerlo con Lookup/GetMetadata + ForEach + Copy. Consulte las plantillas de solución de Copia de archivos de varios contenedores o Migración de datos de Amazon S3 a ADLS Gen2 como ejemplo general.

    • Compruebe si el servicio notifica algún error de limitación en el origen o si el almacén de datos muestra un estado de uso elevado. Si es así, reduzca las cargas de trabajo en el almacén de datos o intente ponerse en contacto con el administrador del almacén de datos para aumentar el límite o los recursos disponibles.

  • En la fase de transferencia, la lectura desde el origen muestra una larga duración de trabajo:

    • Compruebe si la máquina del entorno de ejecución de integración autohospedado tiene una latencia baja al conectarse al almacén de datos de origen. Si el origen está en Azure, puede usar esta herramienta para comprobar la latencia de la máquina de IR autohospedado en las regiones de Azure; es mejor un valor menor.

    • Compruebe si la máquina de IR autohospedado tiene suficiente ancho de banda de entrada para leer y transferir los datos de forma eficaz. Si el almacén de datos de origen está en Azure, puede usar esta herramienta para comprobar la velocidad de descarga.

    • Compruebe la tendencia de uso de memoria y CPU del IR autohospedado en Azure Portal -> su área de trabajo de Data Factory o Synapse -> página Información general. Considere la posibilidad de escalar vertical u horizontalmente el entorno de ejecución de integración si el uso de CPU es alto o hay poca memoria disponible.

    • Adopte el procedimiento recomendado de carga de datos específico del conector si es aplicable. Por ejemplo:

    • Compruebe si el servicio notifica algún error de limitación en el origen o si el almacén de datos registra un uso elevado. Si es así, reduzca las cargas de trabajo en el almacén de datos o intente ponerse en contacto con el administrador del almacén de datos para aumentar el límite o los recursos disponibles.

    • Compruebe el patrón del origen y el receptor de la copia:

      • Si copia datos desde almacenes de datos con la opción de partición habilitada, considere la posibilidad de ajustar gradualmente las copias en paralelo; tenga en cuenta que demasiadas copias en paralelo pueden perjudicar al rendimiento.

      • En caso contrario, considere la posibilidad de dividir un conjunto de datos de gran tamaño en varios conjuntos de datos más pequeños y permitir que esos trabajos de copia se ejecuten simultáneamente, abordando cada uno de ellos una parte de los datos. Puede hacerlo con Lookup/GetMetadata + ForEach + Copy. Consulte las plantillas de solución de Copia de archivos de varios contenedores, Migración de datos de Amazon S3 a ADLS Gen2 o Copia masiva con una tabla de control como ejemplo general.

  • En la fase de transferencia, la escritura en el receptor muestra una larga duración de trabajo:

    • Adopte el procedimiento recomendado de carga de datos específico del conector si es aplicable. Por ejemplo, al copiar datos en Azure Synapse Analytics, use PolyBase o la instrucción COPY.

    • Compruebe si la máquina del IR autohospedado tiene una latencia baja al conectarse al almacén de datos receptor. Si el receptor está en Azure, puede usar esta herramienta para comprobar la latencia de la máquina de IR autohospedado en la región de Azure; es mejor un valor menor.

    • Compruebe si la máquina de IR autohospedado tiene suficiente ancho de banda de salida para transferir y escribir los datos de forma eficaz. Si el almacén de datos receptor está en Azure, puede usar esta herramienta para comprobar la velocidad de carga.

    • Compruebe la tendencia de uso de memoria y CPU del IR autohospedado en Azure Portal -> su área de trabajo de Data Factory o Synapse -> página Información general. Considere la posibilidad de escalar vertical u horizontalmente el entorno de ejecución de integración si el uso de CPU es alto o hay poca memoria disponible.

    • Compruebe si el servicio notifica algún error de limitación en el receptor o si el almacén de datos registra un uso elevado. Si es así, reduzca las cargas de trabajo en el almacén de datos o intente ponerse en contacto con el administrador del almacén de datos para aumentar el límite o los recursos disponibles.

    • Considere la posibilidad de ajustar gradualmente las copias en paralelo; tenga en cuenta que demasiadas copias en paralelo pueden perjudicar el rendimiento.

Rendimiento del conector e IR

En esta sección se exploran algunas guías de solución de problemas de rendimiento para un tipo de conector o entorno de ejecución de integración concretos.

El tiempo de ejecución de la actividad varía según se use Azure IR o IR de red virtual de Azure

El tiempo de ejecución de la actividad varía cuando el conjunto de datos se basa en diferentes entornos de ejecución de integración.

  • Síntomas: El simple cambio de la lista desplegable Servicio vinculado en el conjunto de datos realiza las mismas actividades de canalización, pero tiene tiempos de ejecución radicalmente diferentes. Cuando el conjunto de datos se basa en el entorno de ejecución de integración de la red virtual administrada, tarda más tiempo promedio que la ejecución basada en el entorno de ejecución de integración predeterminado.

  • Causa: Al comprobar los detalles de las ejecuciones de canalización, puede observar que la canalización lenta se ejecuta en el entorno de ejecución de integración de la VNET administrada (Virtual Network), mientras que la normal se ejecuta en Azure IR. Por diseño, el entorno de ejecución de integración de la red virtual administrada lleva más tiempo en la cola que Azure IR, ya que no se reserva un nodo de proceso por instancia del servicio. Por lo tanto, hay una preparación para que se inicie cada actividad de copia y se produce principalmente en la unión a una red virtual y no en Azure IR.

Bajo rendimiento al cargar datos en Azure SQL Database

  • Síntomas: La copia de datos en Azure SQL Database es lenta.

  • Causa: La causa principal del problema suele ser un cuello de botella en el lado de Azure SQL Database. Las posibles causas son las siguientes:

    • El nivel de Azure SQL Database no es suficientemente alto.

    • El uso de la DTU de Azure SQL Database está cerca del 100 %. Puede supervisar el rendimiento y considerar la posibilidad de actualizar el nivel de Azure SQL Database.

    • Los índices no están configurados correctamente. Quite todos los índices antes de la carga de datos y vuelva a crearlos después de completar la carga.

    • WriteBatchSize no es lo suficientemente grande como para ajustarse al tamaño de fila del esquema. Intente aumentar la propiedad para solucionar el problema.

    • En lugar de Bulk Insert, se usa el procedimiento almacenado, cuyo rendimiento es previsiblemente menor.

Tiempo de espera o rendimiento lento al analizar un archivo de Excel de gran tamaño

  • Síntomas:

    • Al crear un conjunto de datos de Excel e importar el esquema de la conexión o el almacenamiento, obtener una vista previa de los datos, enumerar o actualizar las hojas de cálculo, es posible que se produzca un error de tiempo de espera si el tamaño del archivo de Excel es grande.

    • Cuando use la actividad de copia para copiar datos de un archivo de Excel de gran tamaño (>= 100 MB) en otro almacén de datos, es posible que experimente un rendimiento lento o un problema de memoria insuficiente.

  • Causa:

    • En operaciones como la importación de esquemas, la vista previa de datos y la enumeración de hojas de cálculo en un conjunto de datos de Excel, el tiempo de espera es de 100 s y es estático. Para un archivo de Excel de gran tamaño, es posible que estas operaciones no finalicen dentro del valor del tiempo de espera.

    • La actividad de copia lee el archivo de Excel completo en la memoria y, luego, busca la hoja de cálculo y las celdas especificadas para leer los datos. Este comportamiento se debe al SDK subyacente que usa el servicio.

  • Solución:

    • Para importar el esquema, puede generar un archivo de ejemplo más pequeño que sea un subconjunto del archivo original y elegir "Importar esquema de archivo de ejemplo" en lugar de "Importar esquema desde conexión/almacén".

    • Para mostrar una hoja de cálculo, en la lista desplegable de hoja de cálculo, puede hacer clic en "Editar" e introducir en su lugar el nombre/índice de la hoja.

    • Para copiar un archivo de Excel de gran tamaño (>100 MB) en otro almacén, puede usar el origen de Excel de Data Flow cuyo streaming de Sport lee y funciona mejor.

La incidencia de OOM de lectura de archivos JSON/Excel/XML grandes

  • Síntomas: al leer archivos JSON/Excel/XML grandes, se produce la incidencia de memoria insuficiente (OOM) durante la ejecución de la actividad.

  • Causa:

    • Para archivos XML grandes: la incidencia de OOM relacionada con leer archivos XML grandes es por diseño. La causa es que el archivo XML completo debe leerse en la memoria, ya que es un solo objeto y, luego, se deduce el esquema y se recuperan los datos.
    • Para archivos Excel grandes: la incidencia de OOM relacionada con leer archivos Excel grandes es por diseño. La causa es que el SDK (POI/NPOI) usado debe leer todo el archivo de Excel en la memoria y, a continuación, deducir el esquema y obtener datos.
    • Para archivos JSON grandes: el problema de OOM de leer archivos JSON grandes es por diseño cuando el archivo JSON es un solo objeto.

  • Recomendación: aplique una de las siguientes opciones para resolver el problema.

    • Opción-1: registre un entorno de ejecución de integración autohospedado en línea con una máquina eficaz (alta CPU/memoria) para leer datos del archivo grande a través de la actividad de copia.
    • Opción-2: use memoria optimizada y clústeres de gran tamaño (por ejemplo, 48 núcleos) para leer datos del archivo grande a través de la actividad de flujo de datos de asignación.
    • Opción-3: divida el archivo grande en otros más pequeños y, a continuación, use la actividad de flujo de datos de asignación o copia para leer la carpeta.
    • Opción-4: si está bloqueado o se produce la incidencia de OOM durante la copia de la carpeta XML/Excel/JSON, use la actividad foreach + actividad de flujo de datos de asignación y copia en la canalización para controlar cada archivo o subcarpeta.
    • Opción-5: otros:
      • Para XML, use la actividad de Notebook con un clúster optimizado para memoria para leer datos de los archivos si cada archivo tuviera el mismo esquema. Actualmente, Spark tiene diferentes implementaciones para controlar XML.
      • Para JSON, use diferentes formularios de documento (por ejemplo: Documento único, Documento por línea y Matriz de documentos) en la configuración JSON en origen de flujo de datos de asignación. Si el contenido del archivo JSON es Documento por línea, consume muy poca memoria.

Otras referencias

Estas son algunas referencias para la supervisión y la optimización del rendimiento para algunos de los almacenes de datos admitidos:

Contenido relacionado

Consulte los restantes artículos acerca de la actividad de copia: