Moving /tmp off disk into memory (/etc/fstab entry using tmpfs) may resolve your problem.
This tends to be one of my first steps when setting up a new machine or LXD container for my hosting clients.
/tmp gets targeted for two heavy weight activities.
- MariaDB/MySQL temp tables are written/read using /tmp.
These tables get created whenever a complex SQL SELECT exceeds memory buffers.
- PHP session data, to ACL pages can be written here, depending on how all code on your site implements session handling.
When a page transition occurs on your site (moving from one page to the next), the validity of the transition must be determined. This process can involve reading + writing session data many times.
Way better for these activities to run at memory speed, than disk speed.
Also, be sure you’re running…
-
The latest stable Linux Kernel - 4.10 as of today.
-
Your /var/lib/mysql file system is ext4 with mount options of noatime,dioread_nolock.
-
Latest version of MariaDB -10.2.6 as of today. Simply deinstalling MySQL + installing MariaDB fixes many performance problems.
-
Goes without saying you’re best served to be running latest Apache + HTTP2 + SSL - 2.4.26 as of today.
-
And latest PHP - 7.1.6 as of today.
Having your entire LAMP Stack up to date + tuned makes a huge difference.
By tuned, run mysqltuner + mysql-tuning-primer on a regular basis + change whatever’s reported.
Also ensure PHP Opcache memory is sufficient, by tracking this on a regular basis. I usually start with 1G for complex sites.
Also enable you slow query log + track it. Recently I took on a new client who had written custom SQL code which was reading a data table with no indexes, so was reading nearly 1,000,000 rows repeatedly with 0 rows returned.
Both slow query log + the WordPress Query Monitor plugin (which I run on all my client’s production sites) will report areas of slow down.
After you’ve implemented all the LAMP refinements mentioned above, then use Query Monitor to pin point other areas of code which require refactoring/rewriting.