Arcgis Server 10.1 Crack 42
Manric Hock
Somehow our ArcGIS Server doesn't return logs anymore. This is the case in the manager and on the REST endpoint (which is no surprise, as the manager seems to use this endpoint as well). Instead of logs the server is just infinitely 'pending':
1) What is the version and OS for your ArcGIS Server?
2) Is there sufficient space (10 GB's min) on the ArcGIS Server machine's drives for both the install directory and ArcGIS Server config store and directories?
-Christof
In addition to what Christof wrote above, I would make sure that the account running the ArcGIS Server service has access to the logs directory. From the web page you included in the screenshot, you should see a "Settings" icon in the upper right hand corner. Clicking this button will indicate the directory where the ArcGIS Server logs are stored. (By default, this is "C:\arcgisserver\logs\").
We did resolve the issue this morning. The VPS on which the datastore was installed was not responding/operating correctly. After rebooting the VPS everything operated normally. The logs are now available in the manager and on the REST-endpoint.
Even though we fixed the issue, we're not quite sure what role the datastore has in correlation to the logging and why an unreachable datastore(server) would impact the retrieval of the logs. Maybe you could shine some light on this.
We've just come across the same issue and after 2 days of pulling my hair out have found a solution that worked for us. For context, our solution is a highly available Enterprise with the Portal, Server and Datastores on the same machine.
In short, a relational datastore removed itself from one of the machines and caused the primary datastore to save the backups back on the local c drive, not the designated shared folder. This slowly filled the c drive up and caused the primary datastore to enter read-only mode, which we subsequently cleared and set back to read/write with no joy.
We also noticed that the missing datastore would show up when validating in Server Admin or using the describe datastore tool, but not when accessing the datastore configuration :2443/arcgis/datastore
Is it the Datastore or the ArcGIS Server that's doing the heavy lifting when serving up Hosted Feature Services to the Portal? I'm analysing the performance of our system, and looking at ways of spreading the load across our available machines. I read an article that said that the ArcGIS Server ArcSOC for a Hosted Feature Service is just a lightweight REST endpoint and the datastore does the hard work. But I'm not too sure about that.
It's a mix. If you consider a traditional map service, then (in dedicated instances), publishing a service will create an ArcSOC.exe and start consuming memory. If you start using it and max instances are higher than 1 then it may create more ArcSOC.exe's, and this starts to consume an increasing but linear amount of memory. The CPU loading is dependent on how often it's called. The memory usage relates to the fact that it needs to 'make an image' from the data. The internal workflow will be something like:
Clearly, this is a gross simplification. In a hosted feature service, the burn layers step is replaced by 'format data' (JSON/PBF). The manipulation of the text (data) is a much lighter weight computational operation. Importantly it doesn't need a SOC for every service instance. In effect a server that is only used for hosting services needs much less memory than a traditional ArcGIS Server.
In terms of which is doing most, then the Data Store will be doing the data heavy lift, with the Hosting Server doing the conversion to JSON/PBF. Obviously, if a little bit of data is requested then neither has a high workload, but as larger amounts of data re requested then both start to ramp up.
I think it would be fair to say that both are working in tandem. The data stores workload would be somewhat comparable to an Enterprise Geodatabase, but a specific hosting server will need less resources than a traditional ArcGIS Server. Many of my smaller clients run Enterprise Portal, Hosting Server, and Data Store (the Base Deployment) on a single machine, and then traditional server roles on individual machines as required.
I have ArcGIS Pro 2.9.5 installed on my desktop. I have ArcGIS Enterprise 10.9.1 installed on our server. I have administrative access. Please help me find a way, in Python, to list all services that use the ArcMap runtime, in preparation for our upgrade to Enterprise 11. Here is what I have so far:
I have tried accessing several properties of both known_arc*_service objects, and cannot find any indicator in Python as to which one uses the ArcMap runtime and which uses the ArcPro one. Therefore, I can't programmatically find them. We have hundreds of services and it would be great to do this programmatically and not by loading 10 items at a time in ArcGIS Server Manager.
Hi @RogerDunnGIS, I know you're looking to gain this information for your ArcMap-based services via Python but would the UpdateArcMapServices utility help you in this instance? Analysis mode would provide an inventory of your services without migrating them. This blog also goes into a bit more detail about this.
However, ArcGIS Server 10.9.1 offers a button in ArcGIS Server Manager that allows a person to convert their ArcMap run-time service into an ArcPro run-time service. Meanwhile, the source of the service remains the same: an .mxd document. When you look at ArcGIS Server Manager, it says right there under the service description which run-time it's using; I just don't know why it's been so hard for me to find that piece of data using the API.
I appreciate your reply. I'm aware that Server makes a copy of the original ArcMap document, and that sometimes there are changes to it, like when data is copied to the server. What I was trying to explain is that you can have an ArcGIS Server service running with the Pro run-time, even though it was originally published with ArcMap. I explained in the last reply how a user might do that. Once the conversion is done, the original ArcMap document remains in the folder, and Server Manager will continue to report that the original document was an .mxd, even though a service is running with the Pro run-time.
As a Python programmer, I sometimes forget about other tools available that aren't already in ArcToolbox. Of course, Esri provides many tools to users and administrators that are only available in some environments, like Command Prompt. Thank you for your solution.
We have Load Runner scripts to test with up to 200 users and during the test period we are seeing the javaw process spike to almost 70% CPU alone which affects the rest of the machine. I'm assuming that with the additional load and amount of incoming requests this process is struggling to keep up? This in turn starts to affect the performance of the server which affects the test which affects the results etc.
Just as an FYI, the hosting gis server can have extremely high CPU utilisation for javaw, along with significant network sent/received associated with javaw when running expensive queries against a hosted feature layer. You can diagnose this by looking at the response times in the postgresql datastore logs. We had 20+ users querying a poorly designed dataset within seconds of each other which caused the hosting server to grind to a halt. In this case, a single user accessing this hosted feature layer had more impact on hardware than all other users combined.
Yes we have seen this as well, especially when customers publish large nationwide data sets to data store. We have seen a single user take the whole system down while attempting to take 1m contour data offline for a collector workflow. In this instance though data store hasn't been configured. We are testing the performance between 10.3.1 and 10.6.1 after a recent upgrade. The script had multiple errors in it (discovered after he fact) calling bad queries and items that didn't exist - so i think the level of logging has changed drastically and this has a flow on effect to server performance.
b37509886e