Aumentando a velocidade dos scripts Python usando o arcpy

Atualização 4/11/2014

Parece que o script estava sendo desligado na ferramenta Excluir Recursos, então mudei para Truncar Tabela, conforme sugerido na resposta abaixo. Também removi as variáveis ​​não utilizadas da ferramenta de acréscimo.

Atualização 4/10/2014

Eu executei esse script no computador do meu colega de trabalho (a máquina dele tem mais memória E contém ArcGIS 10.0 / Python26) e ele foi executado rapidamente. Viva! Quando meu suporte técnico encontrar o CD do ArcGIS 10.0, instalarei e testarei para ver se isso melhora a velocidade da minha máquina. Para deixar claro, estamos executando o mesmo script, nossa unidade de rede e conexão com o banco de dados são mapeadas de forma idêntica e as instruções de impressão são as mesmas. Vou postar uma atualização aqui assim que isso acontecer.

Terminar atualizações

Preciso aumentar a velocidade de alguns scripts Python que executam atualizações em um banco de dados Oracle. Eu tive esses scripts Python executando bem por mais de um ano, por meio de tarefas agendadas e arquivos em lote para iniciar os scripts. Na semana passada, mudei de um XP para uma máquina com Windows 7 e ArcGIS 10.0 -> 10.1. Desde então, os scripts tornaram-se terrivelmente lentos. Se eu executar esse script usando uma classe de recurso pequena (contendo ~ 20 recursos), ele será executado em 30 segundos. Se eu usar uma classe de recurso médio (~ 80.000 registros), ela será executada em 15 minutos. A classe de recurso que eu realmente preciso transferir rapidamente contém cerca de 1.000.000 de registros - o script só vai até a instrução print para verificar se os arquivos existem (se a instrução no código abaixo). Esse processo levaria apenas 35 minutos para ser concluído na minha máquina XP / ArcGIS 10.0.

Abaixo está o código simplificado com o qual tenho testado. Alguém tem sugestões sobre o que posso fazer para aumentar a velocidade? Obrigado, 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)

Eu queria comentar primeiro, mas depois parecia mais apropriado envolvê-lo como resposta (mesmo que incompleto).

Executei o seu código na minha máquina (laptop de hardware com SSD) anexando uma classe de recurso de banco de dados geográficos a uma classe de recursos de banco de dados geográfico do SQL Server na mesma máquina, o que me levou em torno de 13 min. Não sei ao certo por que a velocidade de execução difere tanto em seu ambiente (10.0 >> 10.1), mas você pediu sugestões sobre o que pode ser feito para aumentar a velocidade , portanto, aqui estão algumas idéias que podem aumentar a velocidade de executar o script.

1) Executo o script a partir da linha de comando, que é equivalente a executar um arquivo .bat (executo o script no formato de 64 bits, tenho o ArcGISx6410.2 Python de 64 bits instalado).

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

Pela minha experiência, geralmente é mais rápido executar a versão de 64 bits do Python para executar operações GP longas e pesadas, como o Append. Então você quer ter certeza de executar esta versão do Python ao executar o script.

2) Eu não recomendaria o uso arcpy.DeleteFeatures_management; é muito mais lento do que executar Truncate Table, pois o último não usa transações de banco de dados, o que melhora o desempenho em relação à exclusão linha por linha.

Você mencionou que o script vai apenas até a instrução print para verificar se os arquivos existem (se a instrução estiver no código) . Há uma boa chance de ele continuar excluindo linha por linha, o que pode ser um processo muito lento quando você acessa uma tabela em um banco de dados Oracle (ou realmente qualquer DBMS) remoto. Tente executar o script com Truncate Table, mas sem Anexar primeiro, apenas para ver a diferença de desempenho no estágio de exclusão.

3) Você parece estar usando "Database Connections\\THIS.sde"o código. No entanto, é melhor consultar o próprio arquivo de conexão (arquivo .sde) com o sistema de arquivos ou o caminho UNC, não a pasta "Conexões de banco de dados" da janela Catálogo. Você pode acessar o arquivo .sde criado em C:\Users\%user%\AppData\Roaming\ESRI\Desktop10.1\ArcCatalog. Você pode mover esse arquivo .sde conforme necessário e colocar na pasta à qual o script Python terá acesso.

4) Na arcpy.Append_managementfunção, você usa alguns parâmetros vazios. Em teoria, isso não deve fazer nenhuma diferença, mas eu sugeriria executar a função sem especificar esses parâmetros apenas porque você não precisa deles. Você nunca sabe o que está acontecendo nos bastidores e se essas cadeias vazias são avaliadas em algum momento e se isso pode afetar o desempenho. Basta seguir arcpy.Append_management(lpFeatures, copyFC, schema_type)e não especificar parâmetros para os quais você não fornece nenhum valor.

5) Desencorajo o uso os.sepao criar um caminho para uma classe de recurso. Use os.path.join(geodatabase,featureclassname)para isso em vez disso. É apenas mais limpo e mais legível.

Você pode adicionar mais detalhes à pergunta depois de tentar as coisas acima e fazer alguns testes e revisão de código.

Algumas boas perguntas para ler para obter mais informações sobre como acelerar os scripts Python no ArcGIS:

Desempenho do ArcGISScripting e grandes conjuntos de dados espaciais

Geoprocessamento em segundo plano (64 bits)

A ferramenta Arcgis CopyFeatures é extremamente lenta ao exportar para SDE

Maneiras de acelerar scripts Python em execução como ferramentas do ArcGIS

Considerações de geoprocessamento para dados do ArcSDE

Espero que este exemplo também ajude a responder à pergunta e esteja em um software mais recente. Ele se baseia nas respostas e comentários mencionados acima.

Configuração:

1. Windows 7
2. SQL Server 2012 R2
3. ArcGIS 10.2.2 (Servidor e Desktop)

A carga precisava ser noturna. Foram ~ 9300 registros e 234 atributos.

O modelo original estava abaixo e foi feito tudo no SQL Server 2012 R2 / SDE (7 minutos via ArcCatalog e 3 horas com python):

1. Excluir linhas da classe de recurso no SDE
2. Criar camada de evento XY da tabela no SQL Server
3. Anexar à classe de recurso no SDE

Como eu a alterei (10 segundos via ArcCatalog e 10 segundos via python):

1. Ferramenta de linhas de exclusão substituída pela ferramenta Truncar para a classe GIS Feature no SDE
2. Exporte a tabela SQL para um FGDB na unidade C local
3. Criar camada de eventos XY na memória local
4. Classe de recurso a Classe de recurso no FGDB na unidade C local
5. ENTÃO Anexe a classe Feature FGDB ao SDE
6. Observe que meu banco de dados do SQL Server está na mesma unidade C do meu FGDB. Pode ficar um pouco mais lento em uma rede, mas ainda assim provavelmente não nas 3 horas que eu estava vendo.

O que ajudou um pouco no modelo original foi substituir as fontes de dados conforme o # 3 recomendado acima. Ele cortou 30 segundos ao executar no ArcCatalog. Com python, ele cortou cerca de 20 minutos. Portanto, é uma variável em velocidade, mas não é a variável mais valiosa a ser abordada no meu caso. Parece que, de acordo com a maioria dos blogs, o SQL Server simplesmente não gosta de carregar muito dados "da memória" (por exemplo, criar uma camada de eventos xy). O SQL / SDE parece preferir um objeto real para carregar. Isso explica por que minhas outras cargas, da mesma maneira, levam 1 minuto, mas esses são apenas 1000 registros com 15 atributos, por isso nunca questionei a eficiência de meus modelos até que essa carga precisasse ser executada todas as noites. Como mencionado, essa carga é de 9000 registros com 236 atributos.

O problema com o desempenho entre 10.0 e 10.1 é que algo nas bibliotecas SDE foi alterado na área de trabalho. Costumávamos postar 1.000.000 por noite e levávamos apenas 45 minutos, após uma atualização de software que levava quase 24 horas. Obviamente, não há problema com os dados e apenas o software foi alterado.

Verifique a versão do geodatabase para garantir que ela corresponda à versão do cliente que está executando o arcpy. Relatamos isso à ESRI sem resposta ou reconhecimento de um bug. É bastante óbvio e o problema começou após o 10.0 SP1.

Além disso, outro teste de copiar / colar é mais rápido que um anexo. Tente fazer isso nas versões 10.0 e 10.1 e o desempenho deve ser semelhante. Isso prova que há algum tipo de bug nas versões anteriores ao anexar geometrias.