Our monitor server has been maxing out the cpu.I know some of it was from creating analysis views and I believe some of it is from services being republished or created. I was curious if anyone has experienced this and had any ideas to fix this.
Hello! I just had the pleasure of debugging this oddity in our server.This happens because of the scheduled observers. The observer that grabs the system metrics is "Metrics - Host Windows". This (for us) is scheduled to occur every 1 minute. Other observers were also scheduled to occur every 1 minute.
In other words, the CPU Utilization is the exact CPU Usage % of when the "Metrics - Host Windows" observer runs. Since other observers run at this exact same time, it causes a brief CPU spike.
If you measure the CPU Spike from Performance Monitor, it exactly matches what Monitor Displays.
Setting "Metrics - Host Windows" to check every 1 minute, and others at other times, creates a much more accurate chart. An example is below.
In below example, system metrics are recorded every 1 minute while all other observers run every 5 minutes. You can see the dramatic spike that happens every 5 minutes.
To be honest, it's a pretty serious configuration flaw with observer scheduling. ESRI should include an option to where we can stagger the observer run times. Example, start running at "00:00:30" with a repeat interval of 1 minute. This would perfectly fix this problem!
Please vote for this idea here!!! https://community.esri.com/t5/arcgis-monitor-ideas/add-start-time-setting-for-observers/idi-p/1712875
Good to know you have addressed this issue as I am having same problem
There is a known performance issue in analysis when using metric name and repeated refresh calls in 2023.2 and older. These issues are fixed in 2023.3.1 patch to be released on January 30. Please install it and hopefully it will address your performance / PostgreSQL high CPU. In the meantime, you can kill long running sessions using PG Admin and not use "offending" analysis until a fix.
It is multiple analysis views doing it but they were mostly created off a just couple views. I will work on recreating them and see if that helps.
Hi @Craig_Lunde,
From your screenshots, I can see that it is the Postgres process using up most of the CPU and that periods of high CPU usage come in waves. Are you able to say which Analysis view in ArcGIS Monitor triggers periods of high CPU usage?
Thanks,
Josh
If you are really worried about it, or have noticed changed behavior, then why not? ESRI support, at least here in the Netherlands, is usually quite willing to help you out.
I wouldn't call a 4h continuous high load associated with working hours a "CPU spike" though...
I am thinking that our map server services are being unregistered then reregistered and when this happens its causing a cpu spike. Should I submit a ticket as to why our map server services are losing connection?
I am not to familiar with ArcGIS Monitor, and have never used it, but from what I've read about its function and see in your images, it is clear any activity tracked by ArcGIS Monitor is directly affected by your user's activity. You can even see the 12:00 to 13:00 lunch dip in the CPU usage of Monitor...
Personally, I wouldn't worry to much about 80-100% cpu usage, unless it directly impacts the usage of Monitor (slow updating, web interface no longer accessible due to time-outs or so, or whatever else blocks you from using it properly).
Instead, having 80-90% of your computing power sitting idle doing nothing is a waste of compute resources and ultimately money. Computers are designed to do work, not to sit idle, and servers and professional workstations are designed to withstand 100% CPU usage for essentially indefinitely. I routinely process global OpenStreetMap data on an HP Z840 workstation with dual CPU's (2x22 cores), which is essentially server hardware packaged in a very large desktop case. I trash it with 100% CPU for days to process the global OpenStreetMap data. Never fails on hardware.
Of course, the high CPU usage may indicate this server is at its limit doing real work, maybe because it needs to monitor a very large enterprise deployment with many users and servers and handle all the traffic for that, and you may need to anticipate a server upgrade if you intend to use it for an even larger enterprise deployment in the future.
Les membres connectés peuvent publier, suivre les mises à jour, et plus encore. Nouveau ici ? Inscrivez-vous gratuitement.
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.
