python.exe przestał działać

9

Skrypt Pythona został napisany około 18 miesięcy temu przez osobę, która odeszła. Dało to wtedy wymagane wyniki. Zostałem poproszony o uruchomienie go ponownie, ale przy różnych danych wejściowych (lepszej rozdzielczości). Zestaw danych wejściowych został podzielony na 20 podzestawów po około 2 700 punktów danych. Jednak skrypt ulega awarii („python.exe przestał działać”) po przetworzeniu około 300 punktów danych (zakres od 295 do 306 i NIE zawsze kończy się niepowodzeniem w tym samym rekordzie).

Jak jego stary (ish), skrypt został napisany przy użyciu arcgisscripting, a nie arcpy. Zasadniczo wykonuje następujące czynności przy użyciu kursorów:

  1. Dla danego punktu oblicz odległość kosztową (używając gp.CostDistance_sa) z odcięciem wynoszącym 60 minut.
  2. Wywołuje gp.ExtractValuesToPoints_sa, aby wyodrębnić wszystkie indywidualne wartości w każdym punkcie danych i wysyła klasę obiektów do geobazy danych pliku.
  3. Odczytuje klasę funkcji utworzoną w punkcie b) powyżej i zapisuje wartości do pliku CSV (pomijając wszelkie punkty z „Brak danych” (wartość -9999)).

Powtarza 1, 2 i 3 dla wszystkich pozostałych punktów danych w pliku wejściowym.

Czas przetwarzania wynosi około Średnio 1 minuta na punkt danych. Oto kilka istotnych specyfikacji technicznych:

  • Komputer ma czterordzeniowy procesor Intel i7-2720QM działający z częstotliwością 2,20 GHz i 8 GB pamięci RAM w systemie Windows 7 (64-bitowym).
  • Wersja Pythona to 2.6.6 (powłoka stwierdza również „[MSC v, 1500 32 bit (Intel)] na win32).
  • Zainstalowana jest również ArcMap 10.0 (SP4).

Próbowałem uruchomić go na innym komputerze (do tej pory bez awarii). Obecnie zadanie działa pomyślnie (ale wolniej) na starszym komputerze i osiągnęło 419 rekordów bez awarii. Odpowiednie specyfikacje dla tego urządzenia to:

  • Procesor Intel Core 2 DUO E7500 o częstotliwości 2,93 GHz z 4 GB pamięci RAM i 64-bitowym systemem Windows 7.
  • Python w wersji 2.5.1 (powłoka stwierdza również „[MSC v, 1310 32 bit (Intel)] na Win32).
  • Zainstalowano ArcMap 9.3 (bez wzmianki o jakichkolwiek dodatkach Service Pack).

Czy ktoś może udzielić porady na temat tego, dlaczego skrypt wydaje się działać przez jakiś czas, a następnie zawiesić się i jak go rozwiązać?

Fakt, że do obsługi skryptu pojawia się (jak dotąd) inny komputer, sugeruje coś „środowiskowego”.


Jako aktualizacja, komputer z systemem ARCGIS 9.3 nadal pomyślnie przetwarza dane i osiągnął 1300 przetworzonych punktów danych (i wciąż się liczy). Kolega również uruchomił dane na swoim komputerze z systemem ARCGIS 10.1 - rozbił się po 267 rekordach przy dwóch różnych okazjach. Chociaż nie jest to jednoznaczne, wspólnym wątkiem wydaje się być to, że Arc 9.3 przetworzy dane, ale Arc 10.x tego nie zrobi.

użytkownik14134
źródło
1
ArcGIS 10.0 używa teraz modułu arcpy (ArcGIS 9.x używa modułu arcgisscripting). Będziesz musiał ponownie skonfigurować kod, aby wywoływał arcpy, a także dostosowywał nazwy dowolnego narzędzia geoprzetwarzania, jeśli chcesz, aby działało w środowisku AGS 10.
dchaboya
5
Nie, to nie w porządku - stare skrypty działające w wersji 9.3 będą nadal działać w wersji 10 i 10.1. Państwo nie trzeba modyfikować gp do arcpy. Możesz nawet przenikać gp i arcpy w skrypcie, jeśli chcesz dodać nową funkcjonalność, ale nie w pełni przekonwertować. ..... dlaczego ta konkretna sprawa ulega awarii powyżej, nie wiem. Moją sugestią jest podzielenie go na sekcje i zobaczenie dokładnie ostatniego narzędzia / funkcji, które miały się wydarzyć, zanim Python
zadzwoni
KHibma, tak, myślę, że ma to sens, ponieważ częściowo działało, gdy uruchomiono z AGS 10.
dchaboya
Czy zmieniono punkty danych? Zakładam, że korzystasz z urządzeń znajdujących się w odległości od sieci drogowej (czas podróży). Nie ma gwarancji, że algorytm przetwarzający punkty danych zarządza punktami dokładnie tak samo przy każdym uruchomieniu procesu. 300 lub 306 lub cokolwiek innego może być przypadkowe. Użyłem NA do analizy kosztów sieci opartej na drogach i lokalizacjach w skrypcie pythonowym i zastanawiam się, czy wypróbowałeś mniejszy podzbiór. Na mojej stacji roboczej prowadziłbym znacznie mniejsze grupy punktów na 60-minutową podróż. Analiza czasu podróży zniszczy moc przetwarzania.
JLP Wisc.
1
Niestety mamy również problemy ze stabilnością arcpy GP (która jest tak naprawdę tylko otoką COM i wygląda na wadliwą). arcpy to jedyny znany mi pakiet witryn, który może spowodować awarię interpretera Pythona. CLJ zasugerował kilka obejść tutaj w odpowiedziach (użyj 64-bitowego GP, kursorów GA itp.), Ale już otrzymaliśmy odpowiedź od ESRI, że te problemy są błędami. Mam nadzieję, że kolejny dodatek Service Pack
poprawi

Odpowiedzi:

1

Jeśli uruchomisz menedżera zadań i zobaczysz, jak pamięć wykonywalna Pythona powiększa pamięć i zanim zginie, przekroczysz 1 GB, możesz skorzystać z aktualizacji do 10.1 64-bitowego geoprzetwarzania.

Jeśli chcesz korzystać z kursorów, możesz skorzystać z nowych kursorów arcpy.da. http://resources.arcgis.com/en/help/main/10.1/index.html#//018w00000008000000

Zaktualizowałem projekt do korzystania z arcpy.da i było to ulepszenie o 2 wielkości.

CLJ
źródło
1

To jest po prostu arkadowy błąd. Możesz spróbować uniknąć czynności powodujących awarię, ale zazwyczaj dzieje się tak przy użyciu różnych narzędzi, gdy są używane do przetwarzania długiej listy danych. Jedynym obejściem, jakie znalazłem, jest zapisanie przez mój skrypt jego postępu na drodze do dysku, więc jeśli uruchomisz ponownie proces, będzie wiedział, skąd go pobrać. Jeśli następnie wyłączysz komunikat debugera systemu Windows, zmieniając rejestr (patrz poniżej), możesz po prostu wielokrotnie wykonywać skrypt w cmd.exe, aż zakończy on całą partię bez konieczności ręcznego zamykania procesu za każdym razem.

Wiem, że jest to okropne obejście, ale dość rzadko zdarza się, aby biblioteka Pythona zabijała interpreter Pythona.

DWORD HKLM or HKCU\Software\Microsoft\Windows\Windows Error Reporting\DontShowUI = "1"
DWORD HKLM or HKCU\Software\Microsoft\Windows\Windows Error Reporting\Disabled = "1"
Lucas Fortini
źródło
0

Czy sprawdziłeś, jak skrypt obsługuje kursory? Moje aplikacje często się zawieszają, gdy zapominam o zamknięciu ich za pomocą jawnych del row, cursor, czasem dopiero po pewnym czasie.

Jeśli to nie pomoże, sugeruję użycie mniejszej części kodu i / lub danych.

Jan Šimbera
źródło