python.exe припинив роботу

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

Як старий (ish), сценарій був написаний з використанням arcgiskcripting, а не 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 не буде.

— користувач14134
джерело

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

— дчабоя

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

— поруками

Хібма, так, я здогадуюсь, це має сенс, оскільки він частково працював при запуску з АГС 10.

— дчабоя

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

— WL 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.

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, іноді лише через деякий час.

Якщо це не допомагає, я б запропонував використовувати меншу частину коду та / або даних.

— Ян Шімбера
джерело