On a multicore machine, does the JVisualVM CPU usage graph show total machine CPU capacity or something else?
As an example, on a machine with 16 cores, if I see CPU usage in JVisualVM going up to 50 percent, does that mean the equivalent of 8 cores fully in use?
I just tested with VisualVM 1.3.2 and the CPU display is calibrated so that 100% is 100% of all cores.
I tested by creating a simple application that entered a tight while loop upon launch. I verified using Activity Monitor that Java was using 100% of one core. In VisualVM it showed approximately 12% CPU usage.
Related
I'm trying to figure out why Liberty is consuming CPU 100% when I enable dropins in my Liberty instance?
I tried the following (searched the Internet):
disabled dynamic polling of config and dropins
increased JVM heap size by adjusting Xms and Xmx
enabled -verbose:gc to see if there are any Garbage Collection activities
There are no GC activities, there is more than enough RAM in the system, however, CPU is at almost 100% when I enable dropins making the system and/or Liberty apps unusable.
This is on AIX 7.1 TL3 with 16 GB of RAM. Liberty is the latest 19.0.0.11, even though I tried this on 19.0.0.10 as well with the same results.
Any suggestions, as I'm out of ideas?
Thanks
I have an implementation of a RNN for sequence classification, on my local machine (Win 10, 16Gb ram) when I run the training, it reaches sometimes 100% memory usage.
When I try to run it on a Azure VM (Linux Ubuntu, 14gb ram) the process get killed as soon as it reaches high ram usages.
I am currently using a batch size of 5000 on the local machine, so I tried to reduce the size for the VM, but even if I put it at 2000, the process got killed anyway.
Also on the vm it gives me warnings:
tensorflow/core/framework/allocator.cc:113] Allocation of 1152000000 exceeds 10% of system memory.
What I don't understand is how the local machine can handle the memory usage, and the vm cannot even if they differ by only 2gb of ram.
Does someone have any clue?
Let me know if you need more information, thanks in advance!
I am running Apache Guacamole on a Google Cloud Compute Engine f1-micro with CentOS 7 because it is free.
Guacamole runs fine for some time (an hour or so) then unexpectantly crashes. I get the ERR_CONNECTION_REFUSED error in Chrome and when running htop I can see that all of the tomcat processes have stopped. To get it running again I just have to restart tomcat.
I have a message saying "Instance "guac" is overutilized. Consider switching to the machine type: g1-small (1 vCPU, 1.7 GB memory)" in the compute engine console.
I have tried limiting the memory allocation to tomcat, but that didn't seem to work.
Any suggestions?
I think the reason for the ERR_CONNECTION_REFUSED is likely due to the VM instance falling short on resources and in order to keep the OS up, process manager shuts down some processes. SSH is one of those processes, and once you reboot the vm, resource will resume operation in full.
As per the "over-utilization" notification recommending g1-small (1 vCPU, 1.7 GB memory)", please note that, f1-micro is a shared-core micro machine type with 0.2 vCPU, 0.60 GB of memory, backed by a shared physical core and is only ideal for running smaller non-resource intensive applications..
Depending on your Tomcat configuration, also note that:
Connecting to a database is an intensive process.
Creating a Tomcat with Google Marketplace, the default VM setting is "VM instance: 1 vCPU + 3.75 GB memory (n1-standard-1) so upgrading to machine type: g1-small (1 vCPU, 1.7 GB memory) so should ideal in your case.
Why was g1 small machine type recommended. Please note that Compute Engine uses the same CPU utilization numbers reported on the Compute Engine dashboard to determine what recommendations to make. These numbers are based on the average utilization of your instances over 60-seconds intervals, so they do not capture short CPU usage spikes.
So, applications with short usage spikes might need to run on a larger machine type than the one recommended by Google, to accommodate these spikes"
In summary my suggestion would be to upgrade as recommended. Also note that, the rightsizing gives warnings when VM is underutilized or overutilized and in this case, it is recommending to increase your VM size due to overutilization and keep in mind that this is only a recommendation based on the available data.
My apologies for a potentially silly question. In my work environment we run multiple VM's using Hyper-V. I poll these VM's SNMP using Observium mainly for graphing purposes. The Host machine is an Intel Xeon E5-2407 # 2.4GHZ x2, my question is if I look at the graphs of the host machine's CPU, it peaks at around 8% CPU utilization. If I check the other VM's they look like:
VM1 - 4 vcore's - 50% / VM2 - 4 vcore's - 45% / VM3 - 2 vcore's - 50% / VM4 - 4 vcore's - 3%
Could it really be possible that the host machine is barely doing any processing even though the actual virtual machines are hitting 50% of their processing power? Do you think that the Hyper-V polling is incorrect? Anyone has any experience with this before?
I would appreciate any feedback, thank you!
Due to nature of virtualization, monitoring CPU utilization inside the VM isn't acurate. Short version: processor scheduling is maintained by hypervisor, so VM doesn't really know how much it consumes.
MSDN article describes this in detail, if you want a solid overview.
I have an ESXi 5.5 server running one virtual machine which is given one socket with two cores. What I want to do is to limit these cores to 1500 MHz each to simulate software behaviour on slow machines. How can I do this?
To improve CPU power efficiency, ESX/ESXi can take advantage of performance states (also known as P-states)
to dynamically adjust CPU frequency to match the demand of running virtual machines. When a CPU runs at
lower frequency, it can also run at lower voltage, which saves power. This type of power management is
typically called Dynamic Voltage and Frequency Scaling (DVFS). ESX/ESXi attempts to adjust CPU frequencies
so that virtual machine performance is not affected.
When a CPU is idle, ESX/ESXi can take advantage of power states (also known as C-states) and put the CPU
in a deep sleep state. As a result, the CPU consumes as little power as possible and can quickly resume from
sleep when necessary.
There are power management policies which you have to select for proper CPU utilization. You select a policy for a host using the vSphere
Client. If you do not select a policy, ESX/ESXi uses High Performance by default.
Prerequisites
ESX/ESXi supports the Enhanced Intel SpeedStep and Enhanced AMD PowerNow! CPU power management
technologies. For the VMkernel to take advantage of the power management capabilities provided by these
technologies, you must enable power management, sometimes called Demand-Based Switching (DBS), in the
BIOS.
Procedure
In the vSphere Client inventory panel, select a host and click the Configuration tab.
Under Hardware, select Power Management and select Properties.
Select a power management policy for the host and click OK.
The policy selection is saved in the host configuration and can be used again at boot time. You can change
it at any time, and it does not require a server reboot.