10.1 Memory Issues

[JustinGreco]

I have installed 10.1 onto a new server and have been experiencing issues with memory usage.  Our current 10 installation of ArcGIS Server utilizes about 12 MB of memory, while 10.1 is utilizing about twice the amount of memory with less services running than on our 10 server.  Also the javaw.exe process grows to over 2,000,000 K.  Has anyone else had issues like this with 10.1?  Tech support did not seem aware of this issue.

[sreeharikottoormadam]

going to wake this thread up...


1. Set log level to Warning.
2. Reduced the min. instance to 0 for all services.
3. Increased the virtual memory to 19 GB

Still javaw.exe is taking more memory and sometimes CPU is running close to 100%.

Updating to version 10.2 will help? Any suggestions?





Thanks & Regards,
Sreehari

[AaronKreag]

Its now April 2015, almost a year since this was commented on.  We have 10.2.2 and much of the same issues.  Can I call this a thread wake up?  I need to go back through and read all of these reply's.  My big question is....did anyone move to 10.3 and see any improvements in performance / stability??

[JustinRodriguez]

Hello Everyone,

I have read through this thread, and it seems that everyone is experiencing similar symptoms, but there could be several different problems here.

I would like to first point everyone to this document:

Anticipating and accommodating users—Documentation (10.3 and 10.3.1) | ArcGIS for Server

Please monitor and adjust your resources as needed. If the ArcGIS for Server is running slowly, but resources are not being strained, then there is probably an issue with the way the services are configured. Adding more instances of heavily used services to allow for more resource usage might be the solution.

If the Server (VM Guest or Physical Machine) is being strained on resources, then the System Admin/GIS Admin must discuss what the best course of action would be:

1. Add more resources to the machine (either RAM or Processing power depending on the resource constraint)

2. Set the instances of services lower

  -The issue with setting the instances lower is that the ArcGIS for Server might perform slower

3. Move resource heavy programs to another machine.

  - A common issue is that programs compete for resources. MSSQL is heavy RAM intensive, and so is ArcGIS for Server. In general, we would not recommend for them to be installed on the same machine. Any resource heavy program can cause an issue though. Either move ArcGIS for Server, or the other programs.

4. *This would be specific to a virtualized environment* The issue could be the Host Machine running the Guests, or the physical machine running the virtual machines, could be constrained for resources. This is a similar issue to number three, but harder to detect. Ensure that the host machine running ArcGIS for Server does not have other Virtual guests possibly hogging the other system resources.

If the server is still acting up, and you believe the resources are indeed sufficient, and you have examined the other issues mentioned above, please contact ESRI Support. There could be an issue related to our software. We are always striving to improve the way our software works, and would love the chance to review and correct the issue you are seeing, or even improve the way our program works. Just as our User Community is always finding new and unique ways to use our product, we are looking for the newest and most efficient ways build our product to handle these new workflows and technologies. Thank you all very much!!

Justin

Esri Support

[SusanJones]

Hi Justin

This is excellent. Thank you.

ArcSDE databases are isolated to a different server. In point 3) are you saying register less data sources with ArcGIS Server?

Susan

[JustinRodriguez]

Hello Susan,

Thank you for the reply.  I would be more than happy to further clarify point three. In this scenario, the Machine (either a physical machine or virtual machine) is short on resources (such as RAM or Processing Power). What I am suggesting is, instead of adding more resources to the machine, you may free up additional resources by moving other software that is heavily dependent on the resources (either RAM or Processing Power).

Some examples of Resource Intensive software is:

MSSQL, Microsoft Exchange, Domain Controllers, Network Monitoring Systems, and much more.

In short, what I am suggesting is to ensure you aren't stifling your servers performance by simply forcing it to compete for resources with another program. If you think that might be the case, move one of the programs.

Thank you very much,

Justin

[SusanJones]

Hi Justin

Can you point us to a best practice guide for administering ArcGIS 10.3?

Thanks

Susan

[AaronKreag]

Susan,

That does not exist.

[JustinRodriguez]

Hello Susan,

We do not have a 'Best Practices' document that I know of, but even if we did, it would probably look more like our resources page. Have a look at this online documentation:

What is ArcGIS for Server?—Documentation (10.3 and 10.3.1) | ArcGIS for Server

There is a menu on the left hand side, and multiple tabs at the top. It has a lot of useful information, and is what we usually rely on here in support. I hope that helps.

Thanks again,

Justin

[Anonymous User]

Just wondering if anyone is running into the soc.exe 's eating more virtual memory than physical memory. We are at 50% utilization of 28GB of RAM and are swapping 56GB with the page file on the server. Is it a matter of asking for more virtual memory?

We are using 10.2.2 Win server 2012 RV VM

[JohnCuthbertson]

We are running 10.2.2 and I thought I would share our javaw memory issues

As you can see the javaw.exe memory usage expanded from late on 20/10 through to 24/10.

This server is the second in our cluster.

The only process running over the weekend was the ArcGIS Cache creation process creating 20 tiles per second.

Our first ArcGIS server was running  the same process creating the same amount of tiles. It's memory profile was..

The cache file creation process began at lunchtime Thursday with 3 cache creation processes on each server, this was increased to 8 on each server at 16:00 and decreased back to 3 on Monday 24 at 8AM.

The changing of the number of processes involves stopping the cache creation process and then starting it again. As can be seen in the first chart this stop/start had no impact on javaw memory hogging.

The javaw process that is consuming the vast majority of the memory has a command line of..

"D:\Program Files\ArcGIS\Server\framework/runtime/jre\bin\javaw" -Dnop -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Dsun.locale.formatasdefault=true -Djava.endorsed.dirs="D:\Program Files\ArcGIS\Server\framework\runtime\tomcat\endorsed" -classpath "D:\Program Files\ArcGIS\Server\framework\runtime\tomcat\bin\bootstrap.jar;D:\Program Files\ArcGIS\Server\framework\runtime\tomcat\bin\tomcat-juli.jar" -Dcatalina.base="D:\Program Files\ArcGIS\Server\framework\runtime\tomcat" -Dcatalina.home="D:\Program Files\ArcGIS\Server\framework\runtime\tomcat" -Dcatalina.log.level="OFF" org.apache.catalina.startup.Bootstrap start

Handle count on server 2 over the period...

And thread count on server 2 over the period..

We have another week of running the cache process (although I think server 2 may need a reboot before then).

Anyone with any ideas of how to better track what the memory is being used for?