We are currently creating some new caches for out two 10.6.1 arcgis server machines. We are creating the caches in the test environment to then transfer them to the production environment to reduce the load on the servers.
We have successfully created the cache in the test environment have attempted transfer the cache over to the production environment. We created the identical service on the production environment and then transferred the cache over into the correct folder and directory which all went to plan. We then restarted the service and checked the rest end point it shows all the relevant scales as can be seen below.
However in server manager in the cache status report it comes back listing only some of the scales up to 8000 that have been cached. After we go to view the cache we can browse to it up to scale 8000 and then we go any lower all the tiles are grey and not coming through even though all the scales are in the cache directory
Wondered if anyone has any suggestions of anything we might be doing wrong or any other suggestions for transferring caches between machines
I do not see something incorrect with your process, the first scales do work also for you new service in the prod ArcGIS Server. You mentioned that all the scales are in the cache directory beyond scale 8000, did you also confirm that the directories for the problematic Level ID's contain the exact number of files as the test server where they were generated? And while there you can verify that the ArcGIS Server account has at least read/write permissions on those directories.
If all the above appear correct, then it's possible that there is a corruption in the status.gdb file geodatabase where the cache status is being read from. You may try deleting the status.gdb (either with a Desktop tool preferably, or directly from Windows Explorer), and then run the Cache Status report from the Server Manager (as in your screenshot above) to generate it again. If it completes and reports 100% of tiles then it was a corruption of the initial status.gdb.
Thanks for replying to my question with your suggestion
Yeah on the couple of attempts that i attempted ti do the transfer i checked that the number of files and the file sizes were exactly the same as I did wonder if any had been missed when doing the transfer. Far as I can tell it has the read write/permissions on those directories is there away to definitely tell?
We had a few spare small caches around on test environment that i tried the same process with moving the cache and deleting the service except this time it only retained one scale of 8000. The scales in the test caches went 8000 to 500, we,tested this to see if it was something to do with the scaling we were using.although unlikely.
One thing i have found with some more testing since asking the original question, is that if i purely do "stop and start" instead of doing save and restart it seems to retain the cache without dropping the lower scales from 8000 downwards. The only problem with this if i ever need do change any service settings and do "save and restart" is that the issue will probably return. We did try this at 10.3.1 a couple of years ago and had a lot of problems when we tried it then although we didn't do as much testing as we are doing now
I did rebuilding the status gdb of one of small tests one and it didn't seem to want to rebuild it. I ended up using arcmap tools to rebuild the status gdb file it came back showing only 8000 as it was only before. This cache is very small compared to the one we are trying move which is around 50GB.
It just seems really strange I don't know if the cache reporting tools symbol is required for a cache to be classed as successful in server manager. As without that coming back it seems to mostly work from the tests we have done. As all the cache information is on the service and in the service settings just not in the reported status
Hope your doing well
Thanks for the follow up and hope all is well with you too! Nice that you found a workaround in the meantime, though it's a bit odd that the tiles appear after a stop and start vs a restart of the service. As for verifying the permissions in Windows Explorer you can right-click on each of the directories containing the caches for each scale >Properties>Security, and verify there that the account running ArcGIS Server is present and has read/write permissions at least.
If you want to look more into improving the behavior of the Cache Status Report tool, you can try to increase the min/max instances of the ReportingTools to something like 2/4 from the default values of 0/3. Then run it again after the ReportingTools service restart with the new values for its instances. Hope some of the above will help!