大约18个月前，一个已经离开的人写了一个python脚本。然后产生了所需的输出。我被要求再次运行它，但是使用不同的（更高分辨率）数据输入。输入数据集已分为20个子集，每个子集约有2700个数据点。但是，在处理了大约300个数据点（范围从295到306，并且并不总是在同一条记录上失败）之后，脚本崩溃（“ python.exe已停止工作”）。
由于脚本年代久远，它是使用arcgisscripting而不是arcpy编写的。广泛地，它使用游标执行以下操作：
- 对于给定的点，以60分钟的旅行时间作为起点计算成本距离（使用gp.CostDistance_sa）。
- 调用gp.ExtractValuesToPoints_sa提取每个数据点上的所有单个值，并将要素类输出到文件地理数据库。
- 读取上面b）中创建的要素类，然后将值写入CSV文件（忽略带有“无数据”的任何点（值-9999））。
对输入文件中的所有剩余数据点重复1、2和3。
处理时间约为 每个数据点平均1分钟。以下是一些相关的技术规格：
- 该PC具有运行于2.20GHz的四核Intel i7-2720QM CPU和运行Windows 7（64位）的8GB RAM。
- Python版本为2.6.6（shell在win32上还声明“ [MSC v，1500 32 bit（Intel）]”）。
- 还安装了ArcMap 10.0（SP4）。
我试过在另一台PC上运行它（到目前为止没有崩溃）。当前，该作业在较旧的PC上运行成功（但速度较慢），并且已达到419条记录而没有崩溃。该机器的相关规格为：
- 英特尔酷睿2 DUO E7500处理器，运行频率为2.93 GHz，具有4 GB RAM和64位Windows 7。
- Python版本2.5.1（shell在win32上还声明了“ [[MSC v，1310 32位（Intel）]]”）。
- 已安装ArcMap 9.3（未提及任何Service Pack）。
有人可以提供一些有关脚本为何会工作一段时间然后崩溃的建议，以及如何解决该问题的建议吗？
（到目前为止）出现了另一台PC处理该脚本的事实，这表明有些“环境”问题。
作为更新，运行ARCGIS 9.3的PC仍在成功处理数据，并且已经处理了1300个数据点（并且仍在计数）。一位同事还在运行ARCGIS 10.1的PC上运行数据-在两次分别记录267条记录后，它崩溃了。尽管不是结论性的，但通用线程似乎是Arc 9.3将处理数据，而Arc 10.x将不处理数据。
1
现在，ArcGIS 10.0使用arcpy模块（ArcGIS 9.x使用arcgisscripting模块）。如果要使其在AGS 10环境中运行，则必须重新配置代码以调用arcpy并调整任何地理处理工具的名称。
—
dchaboya
不，那是不对的-在9.3版中运行的旧脚本将继续在10版和10.1版中运行。你并不需要修改的GP ArcPy中。如果要添加新功能，但不完全转换，则甚至可以在整个脚本中混合gp和arcpy。.....我不知道为什么这个特殊情况会崩溃。我的建议是将其分解为各个部分，并确切地看到在python
—
释放
KHibma，是的，我想这是有道理的，因为它从AGS 10运行时部分起作用
—
。– dchaboya
数据点是否已更改？我假设您正在使用距道路网络（行驶时间）不远的设施。不能保证每次运行过程时，用于处理数据点的算法都对点进行完全相同的管理。300或306或任何巧合。我已经使用NA来基于python脚本中的道路和位置对网络进行成本分析，并且我想知道您是否尝试了较小的子集。我将在工作站上运行更小的点组，以在工作站上运行60分钟。行程时间分析将破坏处理能力。
—
JLP Wisc。
不幸的是，我们还面临着arcpy GP（实际上只是一个COM包装器，而且看起来像是越野车）的稳定性问题。我知道arcpy是唯一的站点程序包，它实际上会使python解释器崩溃。CLJ在答案中建议了一些解决方法（使用64位GP，我们GA游标等），但是我们已经从ESRI那里得到答复，这些问题是bug。希望下一个服务包带来改进这个
—
于尔根Zornig