Performance problems are the bane of many IT services and solutions, and PHP is no different in this respect.
Deadlocks can be especially irritating when they occur, because troubleshooting them can require a lot of legwork, as well as some degree of trial and error.
Of course this only applies if you are not well versed in battling subpar performance brought on by deadlocking. So to give you a head start and help you narrow down your search, here are just three aspects to check up on if PHP gripes are getting your goat.
Image Source: Pixabay
Look into the system load average
Your first port of call is to check up on how the underlying hardware is faring, as this could point you in the direction of a particular hardware-related conundrum, or alternatively indicate that the issue lies elsewhere. This also applies if you are running an SQL database with deadlocking issues, and you can refer to this guide for solving it.
The CPU is perhaps the most significant component to scrutinize, and to start off you should pull up the details on it by running the lscpu prompt.
This prompt will spit out all sorts of information about the CPU, including the number of cores it has available. This is significant because with this piece of information, we can check to see how average levels of system loads stack up against the maximum potential load the CPU can handle.
This is where the uptime prompt needs to be run, in order to return a concise overview of the load average, which will look something like this:
$ uptime
02:21:02 up 12 days, 23:52, 1 user, load average: 1.80, 1.39, 1.26
In this example, let’s assume that our CPU has 8 cores. As we can then see from the load average readout, typical utilization is at between 1 and 2 cores over the period being checked.
The conclusion we can draw from this is that the CPU is not being overworked by some rogue processes, or is not the bottleneck we need to worry about right now.
The upshot is that the performance issue must be related to misconfigured software, and thus the search continues. Being able to put your mind at rest that server hardware is not compromised in some way is always a good starting point.
Explore limit settings
One of the main challenges of successfully maintaining server availability comes as a result of needing to ensure that crucial processes have adequate access to the resources they require to execute successfully.
Luckily you can control this to a degree, and if you find that by sticking with the default settings you are seeing some important processes sidelined and stifled, the time to take action has arrived.
The ulimit prompt is suitable for finding which processes are allocated what proportion of your server’s hardware resources, and for making changes. Running it will bring up an equivalent to the following:
$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 32767
max locked memory (kbytes, -l) 32
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 10240
cpu time (seconds, -t) unlimited
max user processes (-u) 50
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
How you proceed from here is up to you, but if you find that users are running too many processes each, or the amount of memory allocated to processes is not adequate, you can make tweaks and changes here.
This is possible either on a per-user basis, or across entire user groups. Check the limits.conf file to implement broader adjustments if deadlocks and performance hiccups are being encountered.
Consider configuration conundrums
Speaking of config files, this is the third and final area in which to look for issues and make amendments as necessary.
Heading to /etc/php-fpm.conf will let you make modifications via custom configuration files, found in /etc/php-fpm.d. Look to the file www.conf if you indent to tinker with the standard setup, which should resemble this:
pm = dynamic
pm.max_children = 5
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 4
pm.max_requests = 200
Up top, pm = dynamic is currently determining that you are able to modify and select the upper limit of the processes which the server will allow to run simultaneously.
If you do not make any changes, this will remain at its default value, which may not be ideal depending on the status of your server and the uses you intend of it.
Adjusting from dynamic to static will force a predetermined PHP process count to be sustained regardless of what else occurs. Again, this may or may not be useful, depending on the particular performance woes you are faced with.
You can also pick ondemand as the mode, which is not advised as this increases the amount of time it takes for processes to be created, and for them to release their lock on resources. Indeed deadlocks may result from this being misconfigured, so look out for it.
Another excellent weapon in your arsenal is slowlog, a keyword you can search for in the aforementioned www.conf file and elsewhere as well. It will tell you how long any requests take to timeout, and could pinpoint problem processes which are responsible for deadlocks.
Final thoughts
If you are sick and tired of PHP performance issues, it is better to act sooner rather than later to fix them. Any sluggishness with no doubt impacts other users, and so the sooner you remedy it, the sooner normality can be restored and productivity can ramp up once more.
There are many other snafus which might be at play, of course, but hopefully you now have a solid starting point for your further investigations.
Richard Grant
Richard has an established career as a technology consultant, helping business owners and CTOs harness new technologies for their business. He regularly writes and muses about emerging technology.
