Latest Contributions by JoshuaBixby

Although having insufficient paging space can cause memory issues, so too can having too little physical RAM.  The page file and physical RAM work together, and neither one can be a complete substitute for the other.  (I am dismissing the old "I have so much RAM I disabled my page file" argument because that is a terrible idea for many reasons, especially in production server environments.)  There is a limit to how much of a process address space can be paged, i.e., some portion of the process address space always has to remain in physical memory.  Therefore, someone can have a 10 TB page file and still crash an application or system due to too little physical memory.  ... View more

Thanks for sharing what you found.  It used to just be antivirus software that could cause issues, but the breadth and depth of security software has exploded over the past decade, especially in corporate environments.  Often times the big-brother software impacts performance, but occasionally it can break functionality as well. ... View more

Although those URLs can be called externally by end-users, they are used extensively by various ArcGIS Enterprise components in any deployment.  ArcGIS Enterprise isn't a piece of software, it is a system made up of many pieces of software, and those pieces are constantly communicating with each other.  I doubt what you are seeing is abnormal, but if you have concerns then open an Esri Support case. ... View more

I have never come across any documentation related to this subject, but I can't say I would expect to either.  Part of the trouble with sharing information related to this topic is the number of variables/factors involved.  It isn't as simple as "ArcSOC processes use 40% more virtual address space."  We saw some services use nearly the same, although probably 90% used noticeably more, but even then some were 10% more and others were 60% more. The average probably came out to be around 25%-30%. Even without changes in software versions, changes in service configurations or service usage can significantly change memory utilization on the server.  The expectation should never be, set-it-and-forget-it.  Just like any other enterprise IT application, the OS and application should be constantly monitored to determine if resource or configuration changes are needed. ... View more

Without knowing more specifics about how ArcGIS Enterprise is deployed, it is hard for community members to provide feedback.  For example, are you running ArcGIS Enterprise on-premises or in the cloud?  If in the cloud, did you deploy it using one of Esri's tools or deploy it yourself?  Are all the components on the same machine or do you have separate machines for each component?  Are you running High Availability portal?  Are you running multiple-machine ArcGIS Server sites? Etc..... ArcGIS Enterprise isn't a piece of software but a system made up of many pieces of software, and how those individual pieces are deployed can very much influence troubleshooting. ... View more

When discussing defects, it is helpful to provide the bug number.  Most defects, although not all, are searchable through Esri Support website and can be linked to in forums/communities like this one. ... View more

Memory configurations are very specific to machines and applications, so it is hard to give recommendations without knowing quite a bit more information.  While allowing the OS to wholly manage the virtual memory settings is convenient, and maybe sufficient for some groups/organizations given their situations, I doubt you see it being used in many enterprise IT operations. What I can say at this point is that ArcGIS Server 11.x uses more memory than ArcGIS Server 10.x given the exact same services and settings.  Whether that increase requires more RAM or different virtual memory settings on a specific server depends on the amount of existing RAM and existing virtual memory settings. I would encourage your IT folks to monitor various memory counters over time, simply pulling up Task Manager and taking a look a few times during the day is not sufficient.  A spike in traffic can cause a spin-up of more ArcSOC.exe processes which can lead to a momentary spike in memory usage.  If the spike is high enough, it can cause lasting instability in the ArcGIS Server framework processes.  Memory spikes can also be brief enough that casually looking at Task Manager throughout the day won't necessarily catch them. ... View more

The organization I used to work for initially had instability problems with ArcGIS Enterprise 11.x until we analyzed memory utilization of the ArcGIS Enterprise processes and subprocesses.  It turns out the ArcGIS Pro runtime used in ArcGIS Enterprise 11.x results in ArcSOC.exe processes having about 50% increase in total memory footprint.  I say total memory footprint because it wasn't more RAM being used but more virtual address space by the processes.  It turns out we were hitting or nearly hitting the committed memory limit of the server, and the entire ArcGIS Enterprise framework would become unstable at that point.  Once it became unstable, the only option to stabilize it was to stop the ArcGIS Server Windows service and restart it. I suggest you monitor the Committed memory usage of the server, and not just RAM.  If you are getting over 90% committed memory for any period of time, I would update the virtual memory (page file) settings on the server.  ... View more

If you are able to post any of the data, that would help community members provide more in-depth responses.  If you can't share any of the data, can you truncate the tables and at least share an empty SQLite package that has the schema? ... View more

Given it has been nearly 6 years since ArcGIS Pro 2.4 was released, I would take any documentation and comments from back then with a grain of salt, even if they were accurate/correct at the time.  The "memory" workspace has continually, albeit slowly, improved over the releases.  For all intents and purposes, "in_memory" is now a legacy artifact that should not be used. ... View more

Attaching screenshots of code and errors, instead of putting the text of code and errors into the thread, will definitely reduce the number of people that will even bother to look at your question.  If you are asking people for help, make it as easy as possible for them to know your issue. Taking the error messages at face value, you need to pass POINT_X instead of CENTROID_X, POINT_Y instead of CENTROID_Y.  Although the documentation is a bit unclear regarding centroids, since you are working with points it is much clearer to use POINT instead of CENTROID.     ... View more

Sometimes chasing the answer isn't worth the effort.  If creating a new geodatabase and copying everything into it works, why not just start using that GDB and delete the old one?  If the 2.75 GB file keeps coming back, then it is likely worth troubleshooting. ... View more

Question asked and answered at arcgis pro - Using Arcade to make Null Geometry - GIS SE. ... View more