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
Related
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.
Is there any possibility of running Orion ContextBroker on Raspberry Pi with Raspbian OS?
The requirements recommended in the Orion documentation are:
Although we haven't done yet a precise profiling on Orion Context
Broker, tests done in our development and testing environment show
that a host with 2 CPU cores and 4 GB RAM is fine to run the
ContextBroker and MongoDB server. In fact, this is a rather
conservative estimation, Orion Context Broker could run fine also in
systems with a lower resources profile. The critical resource here is
RAM memory, as MongoDB performance is related to the amount of
available RAM to map database files into memory.
Besides the board constrained resources, you will have to search about the equivalent required libraries for RaspbianOS.
There is a discussion about it here:
https://github.com/telefonicaid/fiware-orion/issues/15
i have glassfish 2.1.1 running on top of 32 bit RHEL 4 where i need to frequently deploy and undeploy around 30-40 jbi service assemblies packaged in zip files. I use a shell script where the "asadmin deploy-jbi-service-assembly" and "asadmin start-jbi-service-assembly" commands run inside a loop. A peculiar thing I have encountered is that when I set the heap size of the domains through Xmx jvm option to 2048m, undeployment goes fine, but during deployment, after around 6-7 deployments, the domain crashes. When I reduced the heap size from 2048m to around 1700m, I was able to deploy all assemblies without hiccup. But then after deployment I again have to change the heap size and restart the domains. The server has about 48GB memory with 2 quad core cpus, so resource isn't scarce. This is getting to be a real headache. Anyone help me out ????
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.
What is the minimum amount of RAM that the Weblogic Admin Consoel (version 10.3.2) will run under?
256MB is usually a safe bet but for our larger production domains, we use as much as 512mb. In addition to the domain size, your WLDF settings can affect the required heap size.
On a test system, you can probably get away with 128mb.
4 GB
Setting the memory arguments for the WebLogic application servers for SAS® Financial Management