Anyone Else Seeing an Explosion of *_gdal.sqlite Files in %TEMP%

[JoshuaBixby]

I recently re-imaged a PC to Windows 10 x64 Enterprise Edition.  After re-imaging, I installed ArcGIS Pro 2.0.1 and no other ArcGIS Desktop components (ArcMap, ArcCatalog, etc....).  Sometime after a week or so of installing Pro, I noticed thousands and thousands of *_gdal.sqlite files in my %TEMP% folder.

I cleaned up my temp files and just figured it was tied to the install.  Within 48 hours, I had ~2,500 files back, and I never even launched ArcGIS Pro in that 48 hours!  I tracked the files down to the ArcGISIndexingServer.exe process.  I know there have been some memory-usage issues with that process, FAQ: Why does the ArcGISIndexingServer.exe use a high amount of computer memory? , but I haven't seen others talking about this issues.

The fact that this is a newly re-imaged machine with a clean install of ArcGIS Pro is what has me scratching my head.  My machine is about as default as it ever will be, so I want to understand why either the process needs to create so many temp files or why it doesn't clean up after itself.

If others check their %TEMP% directories, how many *_gdal.sqlite files are there?  If there are some, how many have been generated in the past day or so?

Thanks, Joshua

[LR]

I have a few (~4.8k) with ~80 generated today. It's generating a bunch hourly, with some gaps. Pro was open on the 14th last.

[JoshuaBixby]

Interesting.  It would be good to hear from a few more folks.  My guess is that there is a certain type of geospatial content being indexed that is driving the explosion of temp files, I am just not sure what exactly.  I am also working with Esri Support to see if system administrators can disabled this logging because the small files start to add up when you have hundreds of users running Pro in a virtualized environment.

[ThomasColson]

Wow. Yes. Thousands of them. Agree,  excessive generation of temp files is not sustainable with a large number of users.

[JoshuaBixby]

Progress has been slow with Esri Support thus far.  One comment I got was, "you can disable indexing."  Where to even start on replying to that one.  It appears not all of our users are seeing this behavior, or seeing it to the extent that I am, so I do think it is driven by a specific type of content.  I plan on revisiting this and doing some process monitoring after New Year.

UPDATE:  I did some quick process monitoring, and the issue appears tied to indexing of XLS and XLSX files.  A couple of the directories being indexed just happen to have Excel files in them, and when the indexing service gets to those folders, the temp file explosion begins.  I will work on isolating the issue next week to verify the connection to Excel files.

[ThomasColson]

"One comment I got was, "you can disable indexing."

Imagine if you just bought a new car:

"The tires are out of round and it vibrates violently at highway speeds"

Dealer: "Don't drive it on the highway"

[ThomasColson]

"investigating" the SQL lite files does not reveal anything interesting, what they do, or why such an excessive number of them is generated.

[KoryKramer]

Thomas and bixb0012‌ Support is working directly with development to investigate this issue.  Since Joshua has the case open, remaining communication will happen through that case.  You could circle back to close this thread once the case is closed.

Thank you.

[JoshuaBixby]

I was planning on waiting until the Support case is closed to update this thread and close it out.  I am interested to see what Development finds.  At a minimum, if the files absolutely need to be generated, that the indexing service clears them out after a run is complete.

[JoshuaBixby]

For those who are interested, and are being impacted by this issue, a bug has been logged with Esri Support:

#BUG-000110608: ArcGIS Pro's ArcGISIndexingServer.exe generates thousands of *_gdal.sqlite files in %TEMP% directory