Why ElasticBeans talk shows that the Environment health as Degraded & 100 % of CPU is in use while instance shows normal CPU - amazon-ec2

Health tab on ElasticBeanstalk environment shows 100 % of CPU is in use.
health monitor also shows these metrics
but when I visit the instance monitoring tab, it shows the CPU utilization as normal
running a top command shows this screen
What I can notice is the ST is high so what could be the reason that ElasticBens talk shows loaded CPU while EC2 Monitor shows normal?

I have found the root cause of this issue is that the instance type is t2.micro which are burst-able and this means there are CPU credit that is given to the instance when it process below baseline and there is also launch credit
at my case, it seemed that the instance consumed all the launch credit and also the accumulated CPU credit when it processed above the baseline (Brust)
when this case happens and the instance has no CPU credit, Amazon hypervisor throttled the CPU and increased the Stealing Time to 76%
How I solved this issue?
I added an extra instance to work alongside the throttled one which reduced the load on this instance, it then started accumulating credit and the stealing time went down

Related

timer expired ...abort Jmeter ERROR(Non gui mode) - while running the Load test up to 3000 Users

I was performing the Load test up to 3000 users on 16GB RAM and on EC2 instance. when the user reached 2000+, I got the Error timer expired, ...abort in command prompt. During this period Memory & CPU usage was up to 96%
Let me know is this error occurred due to Memory and CPU usage went up to 96% ?or anything to do with Jmeter scripts. bcoz Up to 1K it was working properly.
According to this answer to the JVM crashes with no frame specified, only “timer expired, abort” it occurs when a fatal error has occurred and the JVM wasn't properly switched off in 2 minutes time frame.
Most probably 3000 users is way too much for your test for that VM. Moreover 96% of usage of CPU and RAM is a little bit too much for me, I would rather stop ramping up the users when CPU/RAM usage starts exceeding 80% of total available capacity.
So the next step would be:
Configure JMeter to ramp-up users gradually, i.e. 3000 users in 15 minutes or so
Make sure to follow JMeter Best Practices
Make sure to setup realtime monitoring of CPU, RAM and other resources
Start your test
See how many virtual users were online when resources usage starts exceeding 80% using ie. Active Threads Over Time listener
If you have 3000 users - you should be good to go, if not - you will need to create another machine and to run JMeter in Distributed Mode

How the "Always On" setting effects CPU usage in Azure webapps

How "Always on" setting effects CPU usage?
When "Always on" is off, the CPU usage is 0% if no one uses it. But after I set it is on, it seems CPU usage is High even no one uses it.
This image is showing the max CPU Percentage every 5 minutes in 24 hours.
This image is showing the average CPU Percentage every 5 minutes in 24 hours.
Is it normal? By the way, the images are from Azure app plan. And I have 3 webapps in the same plan. And all of them have been set "always on" to on.
Always On keeps the host process running. This allows your site to be more responsive to request after significant idle periods. Otherwise, once a request comes in, the App Service will have to cold boot and load into memory before responding to the request.
If you're seeing expectantly high CPU duding an "idle" period, I would start by correlating incoming requests with CPU spikes. Have a look here in order to get a snapshot of activity that's being done while your app service is idle.

Azure Website Kudu HTMLLog Analysis shows Always On with high response time

We deployed our WebAPI as an azure website under the standard plan and have turned on Always On. After getting multiple memory and CPU alerts we decided on checking the logs via xyz.scm.azurewebsites.net. It seems Always ON has a high response time. Could this be causing high memory and CPU issues. Sometimes the alerts come when none is even using the system and auto resolve within 5 mins.
The always on feature only invokes the root of your web app every 5 minutes.
If this is causing high memory or cpu it could be a memory leak within your application because if you don't use the always on feature your process gets recycled on idle.
You should check what your app does if you invoke it with the root path and determine why this is causing high response time.

Constant CPU usage and periodical API requests on Compute Engine Instance

Recently I have deployed a Compute Engine instance developed from LAMP template.
A few days after deployment I started to see constant CPU usage (~8%) and also periodical API requests (each ~30 seconds).
I have not performed any API activity (haven't created any applications) and I see ZERO CPU usage inside the VM.
Any ideas what is happenning?
The API requests solved by redeploying the whole machine, but the CPU usage still remains around 8%

High CPU load but low CPU usage and RAM usage

I am running a mobile website to get the live running status of any train in India. It is http://www.spoturtrain.com . The full code is written in PHP and Nginx is used as the webserver, php-fpm is used as the application server. All php requests are proxied to the app server. During peak traffic hours in the morning, the system load shoots up to 4 but the CPU% and the memory usage is low. Please take a look at the snapshot of the top command of the server.
Th %CPU displayed in the bottom section is per-thread, which means the percentage of one CPU core used by the indicated thread. The CPU(s) section indicates the total amount of available CPU that is being utilized, so it is possible to have one thread reporting that it is using 100% CPU, while only 25% (4 core) or 12.5% (8 core) of the overall CPU cycles are being consumed.
Analyzing thread CPU usage on Linux
You don't really ask a question, so it's hard to tell if you are wanting some advice or just asking to have the numbers explained. As #Charles states, a typical "acceptable" load is 1 per CPU core before noticeable performance degradation occurs, but in the case of PHP running on most web servers, you may (but probably won't in most cases) start noticing problems at anything above 1. Whether or not you do will largely depend on your disk and network I/O.
Whether or not the performance is acceptable for your application isn't something I can answer, but you can take a look at this thread for more places to jump into the options for getting your web server to thread requests.
What is thread safe or non thread safe in PHP
Whether or not you can do anything about it depends on your hosting situation.

Resources