Aumento de la velocidad de los scripts de Python usando arcpy


8

Actualización 4/11/2014

Parece que el script se estaba bloqueando en la herramienta Eliminar características, por lo que cambié a Truncar tabla, como se sugiere en la respuesta a continuación. También eliminé las variables no utilizadas de la herramienta de agregar.

Actualización 4/10/2014

Ejecuté este script en la computadora de mi compañero de trabajo (su máquina tiene más memoria Y contiene ArcGIS 10.0 / Python26) y se ejecutó rápidamente. ¡Hurra! Una vez que mi soporte técnico encuentre el CD ArcGIS 10.0, lo instalaré y probaré para ver si eso mejora la velocidad de mi máquina. Para ser claros, estamos ejecutando el mismo script, nuestra unidad de red y la conexión de la base de datos se asignan de manera idéntica, y las declaraciones de impresión son las mismas. Publicaré una actualización aquí una vez que eso suceda.

Fin de actualizaciones

Necesito aumentar la velocidad de algunos scripts de Python que realizan actualizaciones en una base de datos Oracle. Tuve estos scripts de Python funcionando bien durante un año o más, a través de tareas programadas y archivos por lotes para iniciar los scripts. La semana pasada me mudé de un XP a una máquina con Windows 7 y ArcGIS 10.0 -> 10.1. Desde entonces, los guiones se han vuelto terriblemente lentos. Si ejecuto este script usando una pequeña clase de entidad (que contiene ~ 20 entidades) se ejecuta en 30 segundos. Si uso una clase de entidad media (~ 80,000 registros) se ejecuta en 15 minutos. La clase de entidad que realmente necesito para poder transferir rápidamente contiene aproximadamente 1,000,000 de registros: el script solo llega hasta la declaración de impresión para verificar si existen los archivos (si la declaración en el código a continuación). Este proceso tardaría solo 35 minutos en completarse en mi máquina XP / ArcGIS 10.0.

A continuación se muestra el código simplificado con el que he estado probando. ¿Alguien tiene sugerencias sobre lo que puedo hacer para aumentar la velocidad? Gracias patty

import arcpy, os, sys
from arcpy import env
arcpy.env.overwriteOutput = True
from datetime import datetime
import smtplib
import string
import urllib

#Define variables
inWorkspace = "O:/LANDING_PAD/BOE/example.gdb" 
lpFeatures = inWorkspace + os.sep + "fc1"
outWorkspace =  "Database Connections\\THIS.sde"
arcpy.env.workspace = outWorkspace
workspace = ""
copyFC = outWorkspace + os.sep + "SDE.fc1_1" #The feature class the script will update via delete and append
schema_type = "NO_TEST"
fieldMappings = ""
subtype = ""
t = datetime.now()
print "This script began at: " + str(t)

if arcpy.Exists(lpFeatures) is True and arcpy.Exists(copyFC) is True:
    print "Both files exist. Beginning delete..."
    arcpy.DeleteFeatures_management(copyFC) #(copyFC)

    print "ALL DONE DELETING!"

    arcpy.Append_management(lpFeatures, copyFC, schema_type, fieldMappings, subtype) #Append data from landing pad to db
    print "ALL DONE APPENDING!"
    record_count = arcpy.GetCount_management(lpFeatures)
    print record_count
    r = datetime.now()
    print "This script ended at: " + str(r)

1
No he usado arcpy, pero he escrito Python y muchos sistemas paralelos en C #. ¿Es posible que pueda dividir su trabajo en trozos más pequeños y trabajar sobre ellos en paralelo? Despacha múltiples procesos de Python o intenta usar subprocesos. Puede volverse desordenado, especialmente si arcpy no es seguro para subprocesos, ¡pero puede dar resultado cuando tienes mucho que hacer! Puede ser útil preguntar en Stack Overflow también.
jocull

La lentitud se debe a que está eliminando todas las entidades individuales y agregando a la clase de entidad vacía. ¿Hay alguna razón por la que no pueda eliminar toda la clase de entidad Delete_management()y luego volver a crearla con CopyFeatures_management()o FeatureClassToFeatureClass_conversion()?
nmpeterson

2
¿Ha realizado algún perfil ( docs.python.org/2/library/profile.html ) para determinar dónde está ocurriendo la mayor parte de su procesamiento? Sería interesante ver sus resultados.
Aaron

1
@jocull sí, he pensado en armar algo que use multiprocesamiento, pero estaba un poco atascado en cómo los scripts eran tan rápidos en mi XP / ArcGIS 10.0, y lento en Windows 7 / 10.1. Aaron, sí, sería genial ver dónde está ocurriendo el procesamiento. Examinaré el guión. Gracias, Patty
Patty Jula

Publiqué una actualización arriba. Básicamente, los scripts se ejecutan rápidamente en la máquina de mi compañero de trabajo, lo cual es bueno.
Patty Jula

Respuestas:


7

Primero quería comentar, pero luego me pareció más apropiado envolverlo para que fuera una respuesta (aunque pudiera estar incompleto).

Ejecuté su código en mi máquina (computadora portátil de hardware superior con SSD) agregando una clase de entidad de geodatabase de archivos a una clase de entidad de geodatabase de SQL Server en la misma máquina que me llevó unos 13 minutos. No puedo decir con certeza por qué la velocidad de ejecución difiere tanto en su entorno (10.0 >> 10.1), pero ha pedido sugerencias sobre qué puede hacer para aumentar la velocidad , así que aquí hay algunas ideas que podrían aumentar la velocidad de ejecutar el script.

1) Ejecuto el script desde la línea de comandos, lo que equivale a ejecutar un archivo .bat (ejecuto el script en el sabor de 64 bits, tengo instalado Python ArcGISx6410.2 de 64 bits).

c:\Python27\ArcGISx6410.2\python.exe c:\scripts\appendfc.py

Desde mi experiencia, generalmente es más rápido ejecutar la versión de 64 bits de Python para ejecutar operaciones GP largas y pesadas como Append. Por lo tanto, debe asegurarse de ejecutar esta versión de Python cuando ejecute el script.

2) No recomendaría usar arcpy.DeleteFeatures_management; es mucho más lento que ejecutar Truncate Table ya que este último no utiliza transacciones de base de datos, lo que mejora el rendimiento sobre la eliminación fila por fila.

Usted mencionó que el script solo llega hasta la declaración de impresión para verificar si los archivos existen (si la declaración en el código) . Existe una buena posibilidad de que siga eliminando fila por fila, lo que podría ser un proceso muy lento cuando accede a una tabla en una base de datos remota de Oracle (o realmente cualquier DBMS). Intente ejecutar el script con Truncar tabla, pero sin anexar primero solo para ver la diferencia de rendimiento en la etapa de eliminación.

3) Parece que estás usando "Database Connections\\THIS.sde"el código. Sin embargo, es mejor consultar el archivo de conexión en sí (archivo .sde) con el sistema de archivos o la ruta UNC, no con la carpeta de la ventana del catálogo "Conexiones de base de datos". Puede acceder al archivo .sde creado en C:\Users\%user%\AppData\Roaming\ESRI\Desktop10.1\ArcCatalog. Puede mover este archivo .sde según lo necesite y colocarlo en la carpeta a la que tendrá acceso el script Python.

4) En la arcpy.Append_managementfunción, utiliza un par de parámetros vacíos. En teoría, no debería hacer ninguna diferencia, pero sugeriría ejecutar la función sin especificar esos parámetros solo porque no los necesita. Nunca se sabe qué sucede detrás de escena y si esas cadenas vacías se evalúan en algún momento y si esto puede afectar el rendimiento. Simplemente siga arcpy.Append_management(lpFeatures, copyFC, schema_type)y no especifique parámetros para los que no proporcione ningún valor.

5) Desaliento el uso os.sepal crear una ruta a una clase de entidad. Úselo os.path.join(geodatabase,featureclassname)para eso en su lugar. Es simplemente más limpio y más legible.

Puede agregar más detalles a la pregunta después de haber probado las cosas anteriores y haber realizado algunas pruebas y revisión de código.

Un par de buenas preguntas para leer para obtener más información sobre cómo acelerar los scripts de Python en ArcGIS:

Rendimiento de ArcGISScripting y grandes conjuntos de datos espaciales

Geoprocesamiento en segundo plano (64 bits)

La herramienta Arcgis CopyFeatures es extremadamente lenta al exportar a SDE

Formas de acelerar los scripts de Python que se ejecutan como herramientas ArcGIS

Consideraciones de geoprocesamiento para datos de ArcSDE


Muchas gracias, me salvaste el viernes. Quería agregar que sí, puedo llamar a una base de datos en un archivo por lotes que se llama "Database Connections\\THIS.sde". ¿Quizás esto se deba a que el archivo por lotes solo está iniciando los scripts de Python que usan esta variable? No puedo tener una base de datos llamada THIS database.sdeque me resulte extraña ya que hay un espacio en ella Database Connections. Gracias de nuevo,
Patty Jula

Me alegra que haya sido útil. 1. ¿Cómo se ve el rendimiento ahora? 2. Interesante con "Conexiones de base de datos". Estaba tan seguro de que no puede hacer referencia a esta "carpeta" dentro de la ventana Catálogo cuando no ejecuta el script desde la GUI de ArcGIS Desktop, pero estaba equivocado. He actualizado mi respuesta para reflejar esto. 3. Puede tener el archivo de conexión "this database.sde", los espacios están bien para usar. Pero no puede tener una base de datos en Oracle con espacios, así es como funciona DBMS.
Alex Tereshenkov

El rendimiento ha mejorado ahora. El proceso para ejecutar la clase de entidad de registro de millones (de puntos de direcciones) ahora se ejecuta en la máquina Windows 7 / ArcGIS 10.1 (antes de que se congelara en la herramienta de eliminación de entidades). Se tarda 3 horas en ejecutar todo este proceso. Este proceso tomó 50 minutos en mi máquina XP / 10.0. ¿Es este enlace al que te referías con el punto 1 en tu respuesta?
Patty Jula

@ PattyJula, cierto, es este. No necesita instalar / usar el software de procesamiento en segundo plano que está instalado en la parte superior. Solo necesita usar el sabor de 64 bits de Python al ejecutar su script.
Alex Tereshenkov

Gracias por la sugerencia. He instalado Python de 64 bits más un cliente Oracle de 64 bits. Mis scripts todavía no se ejecutan a la velocidad que corrieron con mi configuración XP / ArcGIS 10.0. Voy a programar la tarea para ejecutar los archivos por lotes y los scripts de Python esta noche, si la velocidad no mejora, es posible que deba configurar otra máquina que ejecute ArcGIS 10.0.
Patty Jula

1

Espero que este ejemplo ayude a responder la pregunta también y esté en un software más nuevo. Se basa en las respuestas y comentarios mencionados anteriormente.

Preparar:

  1. Windows 7
  2. SQL Server 2012 R2
  3. ArcGIS 10.2.2 (servidor y escritorio)

La carga debía ser nocturna. Fue ~ 9300 registros y 234 atributos.

El modelo original estaba debajo y se realizó todo en SQL Server 2012 R2 / SDE (7 minutos a través de ArcCatalog y 3 horas con python):

  1. Eliminar filas de la clase de entidad en SDE
  2. Crear capa de evento XY desde la tabla en SQL Server
  3. Agregar a la clase de entidad en SDE

Cómo lo modifiqué (10 segundos a través de ArcCatalog y 10 segundos a través de Python): •

  1. Se reemplazó la herramienta para eliminar filas con la herramienta Truncar para la clase de entidad SIG en SDE
  2. Exporte la tabla SQL a un FGDB en la unidad C local
  3. Crear capa de evento XY en la memoria local
  4. Clase de entidad a clase de entidad dentro de FGDB en la unidad C local
  5. ENTONCES agregue la clase de entidad FGDB en SDE
  6. Tenga en cuenta que mi base de datos de SQL Server está en la misma unidad C que mi FGDB. Puede ralentizarse un poco a través de una red, pero lo más probable es que no sean las 3 horas que estaba viendo.

Lo que sí ayudó un poco en el modelo original fue reemplazar las fuentes de datos según el # 3 recomendado anteriormente. Se afeitó 30 segundos cuando se ejecuta en ArcCatalog. Con python se afeitó unos 20 minutos. Por lo tanto, es una variable en velocidad, pero no es la variable más valiosa para abordar en mi caso. Parece que, según la mayoría de los blogs, a SQL Server simplemente no le gusta la carga de datos pesados ​​"desde la memoria" (es decir, hacer la capa de eventos xy). SQL / SDE parece preferir un objeto real para cargar. Esto explica por qué mis otras cargas que hago de la misma manera toman 1 minuto, pero esos son solo 1000 registros con 15 atributos, por lo que nunca cuestioné la eficiencia de mis modelos hasta que esta carga debía hacerse todas las noches. Como se mencionó, esta carga es de 9000 registros con 236 atributos.


0

El problema con el rendimiento entre 10.0 y 10.1 es que algo en las bibliotecas SDE se cambió en el escritorio. Solíamos publicar 1,000,000 por noche y solo demoramos 45 minutos, después de una actualización de software, tardó casi 24 horas. Obviamente no hay ningún problema con los datos y solo se cambió el software.

Verifique la versión de la geodatabase para asegurarse de que coincida con la versión del cliente que ejecuta arcpy. Informamos esto a ESRI sin respuesta o reconocimiento de un error. Es bastante obvio y el problema comenzó después de 10.0 SP1.

También otra prueba de copiar / pegar es más rápida que un apéndice intente esto desde 10.0 y 10.1 y el rendimiento debería ser similar. Esto demuestra que hay algún tipo de error en las versiones anteriores al agregar geometrías.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.