8

Ok, so I'm running a rather large Python application based on arcpy on two separate machines - one of them is leaking memory and one is not. Both are running the same operation in the software.

The leaking machines is:

  • A nearly new Lenovo T420s
  • Intel Core i5-2540M processor
  • 8 GB DDR 3 RAM
  • Windows 7 x64 Professional (non-domain joined)
  • 128 GB Toshiba SSD
  • running ArcGIS 10.0 SP4 with pyodbc installed into the Python directory(only third party module installed)

The nonleaking machine is:

  • A 1.5 year old Dell Optiplex 980
  • Intel Core i7 870
  • 8 GB DDR 3 RAM
  • Windows 7 x64 Professional (domain joined)
  • 500 GB Western Digital 7200RPM HDD
  • running a brand new (today due to another issue with ArcGIS) intallation of ArcGIS 10.0 SP4 with pyodbc installed (also the only 3rd party module

I also have this same software running on other machines without leaking, but I haven't run this same operation recently or on SP4, so I'm leaving them out.

The software I'm running is here: https://bitbucket.org/nickrsan/pisces - The segment of it that's running is the mapping module (PISCES.mapping). Basically, it runs off the command line and is taking is input data from a Personal Geodatabase, generating layers based upon returned keys from stored queries, and adding those layers into template mxds and outputting them as PDFs/MXDs. All of the leaking portion uses arcpy.mapping and I suspect that's the culprit.

The nonleaking machine runs the software utilizing approximate 200 MB of RAM the whole time. The leaking machine starts around 150 MB, and slowly winds its way up to around 1.25 GB where arcpy calls (load layer, output PDF, etc) start failing.

Has anyone had any similar experiences? I know arcpy leaks memory sometimes and have had similar (but less severe) situations before. Any suggestions on how to track down a leak like this? Any best practices on the types of things I can do/avoid in arcpy to not have memory leaks? I've been using the gc module, but I think I'm not reading its output correctly. I'm relatively certain that it's not my code, but who knows.

Thanks in advance for your help.

nicksan
  • 1,716
  • 1
  • 12
  • 22
  • same input datasets? – Ragi Yaser Burhum May 25 '12 at 22:19
  • Sorry, yes - I'll edit to make that clearer. Basically, the input dataset is its own - a personal geodatabase in the repository, and I'm running the same command on the software to get it to go into mapping mode. This isn't a script tool that runs with input/output in a normal arcmap session, but instead runs off the command line – nicksan May 25 '12 at 22:22
  • 6
    instead of comparing the hardware differences (very very very very very very unlikely the cause), I would concentrate on the other versions of software around. Version of Python, Windows SPs installed (for example, different versions of the MSVCRT) and such... – Ragi Yaser Burhum May 25 '12 at 22:28
  • Oh interesting. They're both the same version of Python installed by ArcGIS (2.6.5), but they could very well have different C libraries installed, or other libraries. I'll look into this and report back. – nicksan May 25 '12 at 22:32
  • 2
    If you're using a personal geodatabase, I think MDAC might be a factor. Have you checked what version you're running? – Kirk Kuykendall May 26 '12 at 02:11
  • Thanks for the suggestion on MDAC - it's the same on all the computers running this software - 6.1.7601.17514. I'm still looking into the VC differences, and I'm trying to see if I can get a memory profiler running on the code to narrow down where it's occurring, because it's not happening where I thought it was on the export calls. If I disable export in the configuration, it still leaks, so I think I need to figure out where exactly it's happening. Thanks for the suggestions – nicksan May 26 '12 at 15:51
  • 1
    I had to do something similar in this question, it turned out to be a leak in one of the files relating to direct connect: ArcObjects: Memory leak in IFeatureClass.Search (only on SDE with direct connect) – blah238 May 26 '12 at 18:44
  • @nicksan Did you ever discover what's causing the problem? – R.K. Dec 20 '12 at 14:01
  • @R.K., I didn't and wasn't able to devote more time to the problem since my work projects moved away from this software for a bit - Are you experiencing the same issue? I can provide more information if it helps you diagnose a similar problem. – nicksan Dec 26 '12 at 19:28
  • Are you running the exact same version of python? – CLJ Jun 28 '13 at 03:17
  • 4
    This question appears to be off-topic because it is about a problem that the original poster no longer has time to work on, and there is not enough information to diagnose the problem. – BradHards Oct 10 '13 at 02:37

0 Answers0