Server user load notifications
What kind of server user load notifications can I subscribe to and what actions do I need to take?
User load warning
When receiving user load warnings, we advise to analyze the load on the server and inspect the processes that run under the application's user.
To investigate where a high load comes from, you could go to the monitoring overview in Pack and get an indication to see if traffic plays a role here.
More information can be found when SSH-ing into your server. Use the htop command to inspect processes that are causing the load. Make sure to read the docs, and get familiar with all the information it provides, like the load averages.
The VIRT, RES and MEM% columns are indidcators for memory usage, and CPU% for processor usage. The TIME+ comes in handy when inspecting long running processes.
Look at the data and try to spot bottlenecks in your processes that might cause problems, before it's too late with downtime as a potential result.
See background processes for more information related to administring backgound processes.
User load critical
A user load critical notification means that the load created by the application user becomes problematic. Inspect the processes on your server, and determine the cause of the load.
If the load as mainly caused by php-fpm, inspect the logs (tail -f domains/mywebsite.com/var/log/*.log) to find out if we're coping with regular traffic, or bot/unwanted traffic. See access logs for more information.
If the load is caused by regular traffic, it might be an indicator to consider a server upgrade. Contact Sales when not completely sure.
When dealing with bot or other unwanted traffic that is causing critical load thereby degrading performance for regular traffic / users of your application, make sure you block the traffic. See blocking bots for more guidance related to bot blocking.
Performance measures
Monitor the situation and wait
It could be that the load will automatically degrade over time and go back to "normal". Traffic spikes and server heavy operations caused by your application, can result in temporary load spikes on the server without any real issues, but just enough to trigger load warning notifications. In this cases, monitoring the situation and being patience can be enough without the need to kill processes or other impactful measures.
If you suspect your application contains memory leaks or other performance bottlenecks, use application monitoring tooling like New Relic for further application performance analysis and insights.
Kill pending PHP requests and restart PHP processes
IMPORTANT Keep in mind that you should only use those commands when you are sure that running PHP processes are causing issues. Never just blindly kill PHP processes without knowing what you're doing, as it can potentially harm your application and it's users.
Sometimes it's neccesary to kill all pending PHP requests and restart all PHP processes. We can do this using the following Hipex CLI commands:
hipex restart:php
hipex restart:phpfpmKill all running MYSQL queries
IMPORTANT Keep in mind that you should only use those commands when you are sure that running MYSQL queries are causing issues. Never just blindly kill MYSQL queries without knowing what you're doing, as it can potentially harm your application and it's users.
Database queries sometimes get stuck or deadlocked. In this case, the Hipex CLI can be utilized to kill all running queries:
hipex restart:mysqlKill all running bin/magento processes
Sometimes the application can't be reached because of too many running cronjobs. When you are not using the hipex cronjobs, new crons will start even if the old ones are not done yet. This will result in a lot of memory usage, and could slow down your application.
If this is the case, it might be better to kill running crons using the following command:
kill $(ps aux | grep '[b]in/magento' | awk '{print $2}')