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:
- Dla danego punktu oblicz odległość kosztową (używając gp.CostDistance_sa) z odcięciem wynoszącym 60 minut.
- 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.
- 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.
źródło
Odpowiedzi:
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.
źródło
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.
źródło
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.
źródło