перестал работать python.exe

Сценарий Python был написан около 18 месяцев назад человеком, который сейчас ушел. Это произвело требуемые результаты тогда. Меня попросили запустить его снова, но с разными (более точным разрешением) данными. Входной набор данных был разбит на 20 подмножеств примерно по 2700 точек данных в каждом. Тем не менее сценарий аварийно завершает работу («python.exe перестал работать») после обработки примерно 300 точек данных (в диапазоне от 295 до 306, и НЕ всегда происходит сбой на одной и той же записи).

Как и его старый (ish), скрипт был написан с использованием arcgisscripting, а не arcpy. В широком смысле это делает следующее с помощью курсоров:

Для данной точки вычислите расстояние затрат (используя gp.CostDistance_sa) с отсечением 60 минут времени в пути.
Вызывает gp.ExtractValuesToPoints_sa, чтобы извлечь все отдельные значения в каждой точке данных и вывести класс пространственных объектов в файловую базу геоданных.
Считывает класс пространственных объектов, созданный в пункте b) выше, и записывает значения в файл CSV (без точек «Нет данных» (значение -9999)).

Повторяет 1, 2 и 3 для всех оставшихся точек данных во входном файле.

Время обработки составляет ок. 1 минута на точку данных в среднем. Вот некоторые соответствующие технические характеристики:

На ПК установлен четырехъядерный процессор Intel i7-2720QM с тактовой частотой 2,20 ГГц и 8 ГБ ОЗУ под управлением Windows 7 (64-разрядная версия).
Версия Python - 2.6.6 (оболочка также сообщает «[MSC v, 1500 32 бит (Intel)] на win32).
ArcMap 10.0 (SP4) также установлен.

Я попытался запустить его на другом ПК (пока без сбоев). В настоящее время задание успешно выполняется (но медленнее) на старом ПК и достигло 419 записей без сбоев. Соответствующие спецификации для этой машины:

Процессор Intel Core 2 DUO E7500 с тактовой частотой 2,93 ГГц, 4 ГБ оперативной памяти и 64-разрядной ОС Windows 7.
Python версии 2.5.1 (оболочка также сообщает «[MSC v, 1310 32 бит (Intel)] на win32).
ArcMap 9.3 установлен (без упоминания каких-либо пакетов обновления).

Может кто-нибудь предложить какой-нибудь совет о том, почему сценарий работает некоторое время, затем происходит сбой и как его решить?

Тот факт, что для обработки сценария появляется другой компьютер (пока что), предполагает нечто «экологическое».

В качестве обновления ПК с ARCGIS 9.3 все еще успешно обрабатывает данные и достиг 1300 обработанных точек данных (и продолжает подсчитывать). Коллега также запустила данные на своем компьютере, работающем под управлением ARCGIS 10.1 - в двух отдельных случаях произошел сбой после 267 записей. Хотя это и не является окончательным, общая нить выглядит так: Arc 9.3 будет обрабатывать данные, а Arc 10.x - нет.

— user14134
источник

ArcGIS 10.0 теперь использует модуль arcpy (ArcGIS 9.x использует модуль arcgisscripting). Вам придется перенастроить код для вызова arcpy, а также настроить имена любых инструментов геообработки, если вы хотите, чтобы он работал в среде AGS 10.

— Дчабоя

Нет, это не правильно - старые скрипты, которые работали в 9.3, будут продолжать работать в 10 и 10.1. Вам не нужно изменять gp в arcpy. Вы можете даже смешивать gp и arcpy в скрипте, если хотите добавить новые функции, но не полностью конвертировать. ..... почему этот конкретный случай падает выше, я не знаю. Мое предложение состоит в том, чтобы разбить его на разделы и увидеть точно последний инструмент / функцию, которая должна произойти перед

— выпуском

KHibma, да, я догадываюсь, что имеет смысл, поскольку он частично работал при запуске из AGS 10.

— dchaboya

Изменились ли точки данных? Я предполагаю, что вы используете объекты на расстоянии до дорожной сети (время в пути). Нет никакой гарантии, что алгоритм обработки точек данных управляет точками одинаково при каждом запуске процесса. 300 или 306 или что-то еще может быть совпадением. Я использовал NA для анализа стоимости сети на основе дорог и местоположений в скрипте Python, и мне интересно, если вы пробовали меньшее подмножество. Я выполнял гораздо меньшие группы точек на своей рабочей станции в течение 60 минут на моей рабочей станции. Анализ времени в пути разрушит вычислительную мощность.

— JLP Wisc.

К сожалению, мы также сталкиваемся с проблемами стабильности arcpy GP (который на самом деле является просто оболочкой COM и выглядит как глючная). arcpy - единственный известный мне сайт-пакет, который может привести к сбою интерпретатора Python. CLJ предложил некоторые обходные пути здесь в ответах (используйте 64-битный GP, используя GA-курсоры и т. Д.), Но мы уже получили ответ от ESRI, что эти проблемы являются ошибками. Надеемся, что следующий пакет обновлений

— улучшит

Если вы запустите диспетчер задач и увидите, как исполняемый файл python увеличивается в памяти и занимает более 1 ГБ, прежде чем он умрет, вы можете выиграть от обновления до 10.1 64-битной геообработки.

Для повышения производительности, если вы используете курсоры, вы можете воспользоваться новыми курсорами arcpy.da. http://resources.arcgis.com/en/help/main/10.1/index.html#//018w00000008000000

Я обновил проект для использования arcpy.da, и это было улучшение на 2 величины.

— CLJ
источник

Это просто дрянная ошибка. Вы можете попытаться избежать использования шагов, вызывающих сбой, но обычно это происходит под разными инструментами, когда используется для обработки длинного списка данных. Единственный обходной путь, который я нашел, заключается в том, чтобы мой сценарий сохранял свой прогресс по пути на диск, поэтому, если вы перезапустите процесс, он будет знать, откуда его забрать. Если вы затем отключите сообщение отладчика Windows, изменив реестр (см. Ниже), вы можете просто несколько раз выполнить сценарий в cmd.exe, пока он не завершит весь пакет без необходимости вручную закрывать процесс каждый раз между ними.

Я знаю, что это ужасный обходной путь, но довольно редко случается так, что библиотека python убивает интерпретатор python.

DWORD HKLM or HKCU\Software\Microsoft\Windows\Windows Error Reporting\DontShowUI = "1"
DWORD HKLM or HKCU\Software\Microsoft\Windows\Windows Error Reporting\Disabled = "1"

— Лукас Фортини
источник

Вы проверили, как скрипт обрабатывает курсоры? Мои приложения часто зависают, когда я забываю закрыть их, используя явное del row, cursor, иногда только через некоторое время.

Если это не поможет, я бы предложил использовать меньшую часть кода и / или данных.

— Ян Шимбера
источник