Take the 2-minute tour ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

We have a system with 2 SOC servers, and one SOM server, acting on a shared storage area.

We have had performance issues for years, and believe we have worked out why.

There are several file Geodatabases on the Linux box, and on these fgdb, were massive amounts of unreleased lock files (up to 250,000 lock files per gdb). we're currently running diagnostics on the servers, but has anyone come across this before? I was sure ArcGIS would be releasing the lock files when they were no longer needed.

Even hard booting the system led to these lock files still being kept in Linux?

I am no linux expert, and have put this to the linux team, but does anyone know of this, have experienced this or seen this before?

Cheers

share|improve this question
    
Searching for "lock" in the docs for the File GDB API turns up nothing. Still, I wonder if there might be something in there that would clear the locks. –  Kirk Kuykendall May 17 '11 at 16:03
add comment

2 Answers 2

Yes, I have seen this before - ALOT. At my last job, we had a nightly process (.NET ArcObjects) that recreated several large FGDBs from scratch, then pushed FCs from SDE to the FGDBs to feed map services. Only problem was that orphaned .lock files kept the process from being able to delete the FGDB first before recreation. I would have thousands of lock files as well. I would have to stop all of my map services, then go through each FGDB and, in Windows Explorer, manually delete the lock files - a real pain. Unfortunately, I never figured out what the problem was, but we were having major performance issues with that server (Windows Server 2003), and it needed bounced alot - like several times a week. I wondered if it had anything to do with the server going down and then coming back up, because the lock files were orphaned, as it sounds like yours are. Some things to consider:

  1. Do you have process(es) writing to the FGDBs, or users writing to them, or are they just static?
  2. Is this server getting bounced alot or going down often?
  3. You mention ArcGIS Server, so I'm assuming map services are consuming these FGDB FCs? If so, are these services gracefully shutdown/started/bounced when needed?
share|improve this answer
    
Hi Chad, 1. They are static, in this instance 2. It is a dev server, so does get bounced more than normal 3. They appear to be properly, gracefully, shut down. We also noticed that the polling was done at the same time for all map services, which did cause issues. I am looking now at the linux side to see what is holding these locks and I do have a confernce call with ESRI tomorrow, so will bring that up. All in all, I have to say ArcGIS on Linux kind of sucks... –  Hairy May 17 '11 at 16:17
    
What about #2 and #3? –  Chad Cooper May 17 '11 at 16:19
1  
-1 Sorry for the downvote. This really is informative and probably helpful but it's not an answer. It's mostly questions. I think this would be better as a comment. –  Sean May 17 '11 at 16:35
1  
I think my orphaned locks resulted from bouncing my server a lot. Make sure you tell them you've heard of this happening on Windows Server 2003 as well - it appears to not just be a Linux issue. –  Chad Cooper May 17 '11 at 18:40
add comment
up vote 2 down vote accepted

We've been using file databases to server up static data

We've discovered that when closing a server context using context.ReleaseContext() the arcsoc.exe process closes ok, but DOES NOT clean up the *.lock file that it's created in the file database.

As a result, we've accumulated more than 1Million lock files in our static file databases - this was causing significant issues.

Stopping and starting services from the ArcServer manager does delete locks when closing down a service, so why this should behave differently for arcobjects calls is a question for ESRI - this makes no sense to me.

This is easy for us to workaround by manually housekeeping these files but is not very nice behaviour by the system.

We've also, less surprisingly, found that services start much cleaner when using local drives for the data than when using a shared drive.

share|improve this answer
1  
This has gone up to ESRI in Redlands. I'll coem back to it in about 4/5 months then... –  Hairy May 19 '11 at 6:37
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.