How To Install Linux, Apache, MySQL (MariaDB), PHP-FPM (LAMP) Stack on CentOS Stream 9

main menu
PHP Version 8.0.20

This article describes how to install a Web server with application back-end PHP and database back-end MySQL using MariaDB. In continuing the same topic, but with different software from the previous article – How To Install Linux, Nginx, MySQL (MariaDB), PHP-FPM (LEMP) Stack on CentOS Stream 9, where the Web server is Nginx with application back-end PHP-FPM, which is a sort of CGI (FastCGI). In this article, the Web server is Apache and the application is again PHP-FPM, because since the CentOS 8 the Apache mod_php is deprecated.
All the software installed throughout this article is from the CentOS Stream 9 official repositories including the EPEL repository. The machine is installed with a minimal installation of CentOS Stream 9 and there is a how-to here – Network installation of CentOS Stream 9 (20220606.0) – minimal server installation.
Here are the steps to perform:

  1. Install, configure and start the database MariaDB.
  2. Install, configure and start the PHP-FPM and PHP cli.
  3. Install, configure and start the Web server Apache 2.x.
  4. Configure the system – firewall and SELinux.
  5. Test the installation with a phpMyAdmin installation.
  6. Bonus – Apache HTTPS with SSL certificate – self-signed and letsencrypt.

STEP 1) Install, configure and start the database MariaDB.

First, install the MariaDB server by:

dnf install -y mariadb-server

To configure the MariaDB server, the main file is /etc/my.cnf, which just includes all files under the folder /etc/my.cnf.d/

[root@srv ~]# cat /etc/my.cnf
#
# This group is read both both by the client and the server
# use it for options that affect everything
#
[client-server]

#
# include all files from the config directory
#
!includedir /etc/my.cnf.d

[root@srv ~]# ls -altr /etc/my.cnf.d/
total 32
-rw-r--r--.  1 root root  295 Mar 25  2022 client.cnf
-rw-r--r--.  1 root root  120 May 18 07:55 spider.cnf
-rw-r--r--.  1 root root  232 May 18 07:55 mysql-clients.cnf
-rw-r--r--.  1 root root  763 May 18 07:55 enable_encryption.preset
-rw-r--r--.  1 root root 1458 Jun 13 13:24 mariadb-server.cnf
-rw-r--r--.  1 root root   42 Jun 13 13:29 auth_gssapi.cnf
drwxr-xr-x.  2 root root 4096 Oct  6 06:34 .
drwxr-xr-x. 81 root root 4096 Oct  6 06:34 ..

The most important file for the MariaDB server is /etc/my.cnf.d/mariadb-server.cnf, where all the server options are included. Under section “[mysqld]” add options to tune the MariaDB server. Supported options could be found here: https://mariadb.com/kb/en/mysqld-options/
Add the following options under “[mysqld]” in /etc/my.cnf.d/mariadb-server.cnf
Keep on reading!

How To Install Linux, Nginx, MySQL (MariaDB), PHP-FPM (LEMP) Stack on CentOS Stream 9

main menu
dnf mariadb

This article presents how to install a Web server with application back-end PHP and database back-end MySQL using MariaDB. All the software installed throughout this article is from the CentOS Stream 9 official repositories including the EPEL repository. The machine is installed with a minimal installation of CentOS Stream 9 and there is a how-to here – Network installation of CentOS Stream 9 (20220606.0) – minimal server installation.
Here are the steps to perform:

  1. Install, configure and start the database MariaDB.
  2. Install, configure and start the PHP-FPM and PHP cli.
  3. Install, configure and start the Web server Nginx.
  4. Configure the system – firewall and SELinux.
  5. Test the installation with a phpMyAdmin installation.
  6. Bonus – Nginx HTTPS with SSL certificate – self-signed and letsencrypt.

STEP 1) Install, configure and start the database MariaDB.

First, install the MariaDB server by:

dnf install -y mariadb-server

To configure the MariaDB server, the main file is /etc/my.cnf, which just includes all files under the folder /etc/my.cnf.d/

[root@srv ~]# cat /etc/my.cnf
#
# This group is read both both by the client and the server
# use it for options that affect everything
#
[client-server]

#
# include all files from the config directory
#
!includedir /etc/my.cnf.d

[root@srv ~]# ls -altr /etc/my.cnf.d/
total 32
-rw-r--r--.  1 root root  295 Mar 25  2022 client.cnf
-rw-r--r--.  1 root root  120 May 18 07:55 spider.cnf
-rw-r--r--.  1 root root  232 May 18 07:55 mysql-clients.cnf
-rw-r--r--.  1 root root  763 May 18 07:55 enable_encryption.preset
-rw-r--r--.  1 root root 1458 Jun 13 13:24 mariadb-server.cnf
-rw-r--r--.  1 root root   42 Jun 13 13:29 auth_gssapi.cnf
drwxr-xr-x.  2 root root 4096 Oct  6 06:34 .
drwxr-xr-x. 81 root root 4096 Oct  6 06:34 ..

The most important file for the MariaDB server is /etc/my.cnf.d/mariadb-server.cnf, where all the server options are included. Under section “[mysqld]” add options to tune the MariaDB server. Supported options could be found here: https://mariadb.com/kb/en/mysqld-options/
Add the following options under “[mysqld]” in /etc/my.cnf.d/mariadb-server.cnf
Keep on reading!

Gentoo emerge GO lang failed – atomic_amd64x.go: too many errors

Upgrading GO lang under Gentoo maybe a little bit tricky. The upgrading go lang from 1.13.7 to 1.15.5 failed with strange error:

# runtime/internal/atomic
/usr/lib/go/src/runtime/internal/atomic/atomic_amd64x.go:18:6: Load redeclared in this block
        previous declaration at /usr/lib/go/src/runtime/internal/atomic/atomic_amd64.go:16:24
/usr/lib/go/src/runtime/internal/atomic/atomic_amd64x.go:24:6: Loadp redeclared in this block
        previous declaration at /usr/lib/go/src/runtime/internal/atomic/atomic_amd64.go:22:32
/usr/lib/go/src/runtime/internal/atomic/atomic_amd64x.go:30:6: Load64 redeclared in this block
        previous declaration at /usr/lib/go/src/runtime/internal/atomic/atomic_amd64.go:28:26
/usr/lib/go/src/runtime/internal/atomic/atomic_amd64x.go:36:6: LoadAcq redeclared in this block
        previous declaration at /usr/lib/go/src/runtime/internal/atomic/atomic_amd64.go:34:27
/usr/lib/go/src/runtime/internal/atomic/atomic_amd64x.go:41:6: Xadd redeclared in this block
        previous declaration at /usr/lib/go/src/runtime/internal/atomic/atomic_amd64.go:39:37
/usr/lib/go/src/runtime/internal/atomic/atomic_amd64x.go:44:6: Xadd64 redeclared in this block
        previous declaration at /usr/lib/go/src/runtime/internal/atomic/atomic_amd64.go:42:39
/usr/lib/go/src/runtime/internal/atomic/atomic_amd64x.go:47:6: Xadduintptr redeclared in this block
        previous declaration at /usr/lib/go/src/runtime/internal/atomic/atomic_amd64.go:45:47
/usr/lib/go/src/runtime/internal/atomic/atomic_amd64x.go:50:6: Xchg redeclared in this block
        previous declaration at /usr/lib/go/src/runtime/internal/atomic/atomic_amd64.go:48:36
/usr/lib/go/src/runtime/internal/atomic/atomic_amd64x.go:53:6: Xchg64 redeclared in this block
        previous declaration at /usr/lib/go/src/runtime/internal/atomic/atomic_amd64.go:51:38
/usr/lib/go/src/runtime/internal/atomic/atomic_amd64x.go:56:6: Xchguintptr redeclared in this block
        previous declaration at /usr/lib/go/src/runtime/internal/atomic/atomic_amd64.go:54:45
/usr/lib/go/src/runtime/internal/atomic/atomic_amd64x.go:56:6: too many errors

Googling a little bit and it appeared there might be a conflict with the old version in the same directory. Deleting the temporary build directory didn’t help…

Removing the GO lang package by unmerge command and then emerging the newest GO lang package is successful.

So the solution is to unmerge it and then immediately emerge the newest version with:

emerge -vC dev-lang/go
emerge -v dev-lang/go

The whole Gentoo output of the failed emerge command

Keep on reading!

Ubuntu with PHP 7.2 and mcrypt module

As mentioned in our previous article PHP 7.2 or PHP 7.3 with mcrypt – manual build the PHP versions 7.2 and 7.3 do not include PHP mcrypt module. The mcrypt module was part of PHP 5 till 7.1, in which it was deprecated and removed in 7.2.
In this article we show how to build mcrypt module for Ubuntu based on our previous article showed above. Because of the great popularity of Ubuntu and it has no PHP mcrypt package in Ubuntu package system unlike other Linux distributions (like Gentoo, which created a package) we decided to make this article.

For our purpose we use Ubuntu 18.04.2 LTS and here is what the steps to have the mcrypt PHP module:

STEP 1) Update and install mcrypt library and header development packet

sudo apt update -y
sudo apt install -y libmcrypt-dev

STEP 2) Install the GNU GCC build utility and the PHP dev packet

This is the compiler to build the module.

sudo apt install -y build-essential
sudo apt install -y php7.2-dev

STEP 3) Download the PHP mcrypt module and build it.

cd
mkdir mcrypt-php-module-manual
cd mcrypt-php-module-manual
wget https://pecl.php.net/get/mcrypt-1.0.2.tgz
tar xzf mcrypt-1.0.2.tgz
cd mcrypt-1.0.2
phpize
aclocal
libtoolize --force
autoheader
autoconf
./configure
make
sudo make install

STEP 4) Load the module in the PHP configuration (we use PHP-FPM and PHP-CLI) and block future PHP versions to be installed when apt update is used.

Because we compile the PHP mcrypt module for the specific currently installed PHP we do not want to upgrade our PHP when there is an update and the mcrypt module to fail to load. Each change of the PHP version (upgrade) would require a recompile against the current PHP version. To see more for holding and unholding Ubuntu packages – apt-mark – upgrade with the exception of certain packages Of course, if there is an update for PHP you must install it just recompile the mcrypt package, too!

echo "extension=mcrypt.so" > 20-mcrypt.ini
sudo cp 20-mcrypt.ini /etc/php/7.2/cli/conf.d/20-mcrypt.ini
sudo cp 20-mcrypt.ini /etc/php/7.2/fpm/conf.d/20-mcrypt.ini
sudo apt-mark hold php-cli php7.2-cli php-fpm php7.2-fpm

Keep on reading!

PHP 7.2 or PHP 7.3 with mcrypt – manual build

Newer PHP versions do not include PHP mcrypt library. The mcrypt module was part of PHP 5 till 7.1, in which it was deprecated and removed in 7.2. If you open the php.net documentation for mcrypt PHP functions you will see:

This function has been DEPRECATED as of PHP 7.1.0 and REMOVED as of PHP 7.2.0. Relying on this function is highly discouraged.

The mcrypt module is now in PHP PECL (repository for PHP Extensions) in https://pecl.php.net/package/mcrypt. As you can see in the description, this is a legacy module, which

Provides bindings for the unmaintained libmcrypt.

, so it is strongly recommended to replace it with OpenSSL (for example).
Still, if you need this legacy module – mcrypt and :

You may want to manually build the mcrypt module for your current installed PHP. Of course, the generic dependencies are:

  1. libmcrypt and its headers (if the Linux distribution) splits the binary and the headers
  2. GNU GCC
  3. PHP 7.2+
  4. download the latest mcrypt module source from https://pecl.php.net/package/mcrypt. For example, now it is https://pecl.php.net/get/mcrypt-1.0.2.tgz
mkdir /root/mcrypt-php-module-manual
cd /root/mcrypt-php-module-manual
wget https://pecl.php.net/get/mcrypt-1.0.2.tgz
tar xzf mcrypt-1.0.2.tgz
cd mcrypt-1.0.2
phpize
aclocal
libtoolize --force
autoheader
autoconf
./configure
make
make install

Do not use “make -j N” (“make -j 8”, for example), because it may fail to compile.
Keep on reading!

nginx with php fpm (fastcgi) and the warning – an upstream response is buffered to a temporary file /var/cache/nginx/fastcgi_temp

As the web grows and the technology advances the page size of the web sites also grows or just some times you might want to output a big chunk of data from your application server – PHP-FPM (but it could be any of another ruby, python, C, Django and more), for example.
Here is a fast configuration tip (note this is not the proxy-related warning!):

The default nginx buffers per CGI connection are too small

Here is what to do in your nginx configuration file:
First, look for a line “include /etc/nginx/fastcgi_params;” or similar and add or edit if they exist after this line:

        fastcgi_buffer_size 16k;
        fastcgi_buffers 32 16k;

Check out more for the buffers here http://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_buffers
The warning should stop if it does not stop you can try raising them. It could consume more memory but could lower the IO usage of your disks and improve the performance of your site or whatever backend works!

Here is the warning in our nginx error logs. We got this warning when using php-fpm and the php output size was 325965 bytes (~320K).

2019/04/04 09:56:05 [warn] 24451#24451: *44269838 an upstream response is buffered to a temporary file /var/cache/nginx/fastcgi_temp/0/12/0019966120 while reading upstream, client: 10.10.10.10, server: srv17.srv.en, request: "GET /api/20140102/product HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "srv17.srv.en"
2019/04/04 09:56:07 [warn] 24451#24451: *44269849 an upstream response is buffered to a temporary file /var/cache/nginx/fastcgi_temp/2/12/0019966122 while reading upstream, client: 10.10.10.11, server: srv17.srv.en, request: "GET /api/20140102/product HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "srv17.srv.en"
2019/04/04 09:56:09 [warn] 24450#24450: *44269856 an upstream response is buffered to a temporary file /var/cache/nginx/fastcgi_temp/7/12/0019966127 while reading upstream, client: 10.10.10.12, server: srv17.srv.en, request: "GET /api/20140102/product HTTP/1.1", upstream: "fastcgi://127.0.0.1:9000", host: "srv17.srv.en"

php-fpm memcached – Unknown: Failed to write session data (memcached) when using persistent connections

Several reports in the Internet with such error:

[22-Mar-2019 21:35:20 Africa/Tunis] PHP Warning:  Unknown: Failed to write session data (memcached). Please verify that the current setting of session.save_path is correct (PERSISTENT=2 10.10.10.10:11211) in Unknown on line 0
[22-Mar-2019 21:35:21 Africa/Lagos] PHP Warning:  Unknown: Failed to write session data (memcached). Please verify that the current setting of session.save_path is correct (PERSISTENT=2 10.10.10.10:11211) in Unknown on line 0
[22-Mar-2019 13:35:21 America/Los_Angeles] PHP Warning:  Unknown: Failed to write session data (memcached). Please verify that the current setting of session.save_path is correct (PERSISTENT=2 10.10.10.10:11211) in Unknown on line 0

But no real solutions worked for us. Here is our setup:

Several web servers servers (using php-fpm – fastcgi) connect to a single memcached server to share sessions.

The PHP configuration (php.ini) is as simple as that:

....
session.save_handler = memcached
session.save_path = "PERSISTENT=2 10.10.10.10:11211"
....

This is how you can enable PHP sessions to be stored in the memcached server with IP 10.10.10.10 and tell the driver to use persistent connections. Note we use the binary PHP module memcached, not memcache, which is the old driver.

The persistence is handled by the PHP module, not the library, which it wraps and it is per process not per all PHP fpm (fastcgi) processes.
Apparently, sometimes this functionality just get corrupted and many of those errors begin to appear in the logs – most of the time a reload of the php-fpm after a long period of time. Even a restart did not help, so the real solution, which always works for us is

to change the ID of the “PERSISTENT=”

so just change to:

session.save_path = "PERSISTENT=234 10.10.10.10:11211"

No matter of the ID just some new one, not used previous time! And everything continues smooth!

PHP missing xml extension – Fatal error: Uncaught Error: Class DOMDocument not found

We upgraded one of our servers and at first did not notice this error. Soon logs began to fill with this error:

 Fatal error: Uncaught Error: Class 'DOMDocument' not found in /var/www/htdocs/site1/wp-content/plugins/all-in-one-seo-pack/aioseop_class.php:4501 Stack trace: #0 /var/www/htdocs/site1/wp-content/plugins/all-in-one-seo-pack/aioseop_class.php(4056): All_in_One_SEO_Pack->get_prev_next_links(Object(WP_Post)) #1 /var/www/htdocs/site1/wp-includes/class-wp-hook.php(286): All_in_One_SEO_Pack->wp_head('') #2 /var/www/htdocs/site1/wp-includes/class-wp-hook.php(310): WP_Hook->apply_filters(NULL, Array) #3 /var/www/htdocs/site1/wp-includes/plugin.php(465): WP_Hook->do_action(Array) #4 /var/www/htdocs/site1/wp-includes/general-template.php(2668): do_action('wp_head') #5 /var/www/htdocs/site1/wp-content/themes/twentysixteen/header.php(21): wp_head() #6 /var/www/htdocs/site1/wp-includes/template.php(704): require_once('/var/www/h...') #7 /var/www/htdocs/site1/wp-includes/template.php(653): load_template('/var/www/h...', true) #8 /var/www/htdocs/site1/wp-incl in /var/www/htdocs/site1/wp-content/plugins/all-in-one-seo-pack/aioseop_class.php on line 4501

Apparently, we missed to install all PHP extensions as before and one of our WordPress plugins (All in One SEO Pack) began to throw this nasty error and blank pages, where the error is supposed to be shown!

The fix is easy enough just install PHP-XML

CentOS 7

  • default PHP:
    yum -y install php-xml
    
  • Using ius-release repo:
    yum -y install php72u-xml
    

Ubuntu 16/17/18

sudo apt install -y php-xml php-dom

Gentoo

Just add to your current USE the following “xml” in your /etc/portage/make.conf and emerge (be sure “xml” is in USE emerge output, not “-xml”!):

srv1 ~ # emerge -va --nodeps php

These are the packages that would be merged, in order:

[ebuild   R    ] dev-lang/php-7.2.10:7.2::gentoo  USE="acl apache2 bcmath berkdb bzip2 calendar cgi cli ctype curl exif fileinfo filter fpm ftp gd gdbm hash iconv ipv6 json mhash mysql mysqli nls opcache pcntl pdo phar posix readline session sharedmem simplexml snmp soap sockets sqlite ssl tokenizer truetype unicode xml xmlreader xmlrpc xmlwriter zip zlib -argon2 -cdb -cjk -coverage -debug -embed -enchant -firebird -flatfile -gmp -imap -inifile -intl -iodbc -kerberos -ldap -ldap-sasl -libedit -libressl -lmdb -mssql -oci8-instant-client -odbc -phpdbg -postgres -qdbm -recode (-selinux) -session-mm -sodium -spell -systemd -sysvipc -test -threads -tidy -tokyocabinet -wddx -webp -xpm -xslt -zip-encryption" 0 KiB

Bonus

Here is how our WordPress page looks like with the error:

 <!DOCTYPE html>
<html lang="en-US" class="no-js">
<head>
	<meta charset="UTF-8">
	<meta name="viewport" content="width=device-width, initial-scale=1">
	<link rel="profile" href="http://gmpg.org/xfn/11">
		<link rel="pingback" href="https://ahelpme.com/xmlrpc.php">
		<script>(function(html){html.className = html.className.replace(/\bno-js\b/,'js')})(document.documentElement);</script>
<title>How to compile xmr-stak (2.4.5) under CentOS 7 for CPU mining cryptocurrencies | Any IT here? Help Me! - Part 2</title>

<!-- All in One SEO Pack 2.12 by Michael Torbert of Semper Fi Web Design[387,517] -->
<br />
<b>Fatal error</b>:  Uncaught Error: Class 'DOMDocument' not found in /var/www/htdocs/site1/wp-content/plugins/all-in-one-seo-pack/aioseop_class.php:4501
Stack trace:
#0 /var/www/htdocs/site1/wp-content/plugins/all-in-one-seo-pack/aioseop_class.php(4056): All_in_One_SEO_Pack-&gt;get_prev_next_links(Object(WP_Post))
#1 /var/www/htdocs/site1/wp-includes/class-wp-hook.php(286): All_in_One_SEO_Pack-&gt;wp_head('')
#2 /var/www/htdocs/site1/wp-includes/class-wp-hook.php(310): WP_Hook-&gt;apply_filters(NULL, Array)
#3 /var/www/htdocs/site1/wp-includes/plugin.php(465): WP_Hook-&gt;do_action(Array)
#4 /var/www/htdocs/site1/wp-includes/general-template.php(2668): do_action('wp_head')
#5 /var/www/htdocs/site1/wp-content/themes/twentysixteen/header.php(21): wp_head()
#6 /var/www/htdocs/site1/wp-includes/template.php(704): require_once('/var/www/h...')
#7 /var/www/htdocs/site1/wp-includes/template.php(653): load_template('/var/www/h...', true)
#8 /var/www/htdocs/site1/wp-incl in <b>/var/www/htdocs/site1/wp-content/plugins/all-in-one-seo-pack/aioseop_class.php</b> on line <b>4501</b><br />

And here is what you can expect in your web server logs (nginx + php-fpm setup)

2019/02/23 03:36:14 [error] 27441#27441: *56837 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Uncaught Error: Class 'DOMDocument' not found in /var/www/htdocs/site1/root/wp-content/plugins/all-in-one-seo-pack/aioseop_class.php:4501
Stack trace:
#0 /var/www/htdocs/site1/root/wp-content/plugins/all-in-one-seo-pack/aioseop_class.php(4056): All_in_One_SEO_Pack->get_prev_next_links(Object(WP_Post))
#1 /var/www/htdocs/site1/root/wp-includes/class-wp-hook.php(286): All_in_One_SEO_Pack->wp_head('')
#2 /var/www/htdocs/site1/root/wp-includes/class-wp-hook.php(310): WP_Hook->apply_filters(NULL, Array)
#3 /var/www/htdocs/site1/root/wp-includes/plugin.php(465): WP_Hook->do_action(Array)
#4 /var/www/htdocs/site1/root/wp-includes/general-template.php(2668): do_action('wp_head')
#5 /var/www/htdocs/site1/root/wp-content/themes/twentysixteen/header.php(21): wp_head()
#6 /var/www/htdocs/site1/root/wp-includes/template.php(704): require_once('/var/www/h...')
#7 /var/www/htdocs/site1/root/wp-includes/template.php(653): load_template('/var/www/h...', true)
#8 /" while reading response header from upstream, client: 66.249.79.133, server: ahelpme.com, request: "GET /linux/fedora/review-of-freshly-installed-fedora-29-kde-plasma-desktop-kde-gui/2/ HTTP/1.1", upstream: "fastcgi://192.168.0.12:9000", host: "ahelpme.com"

And keep in mind if your HTTP 405 codes get in your access logs:

10.10.10.2 - - [22/Feb/2019:05:20:34 +0000] "GET /xmlrpc.php HTTP/1.1" 405 53 "-" "Mozilla/5.0 (X11; Linux i686; rv:2.0.1) Gecko/20100101 Firefox/4.0.1" "-"
10.10.10.2 - - [22/Feb/2019:05:20:38 +0000] "GET /xmlrpc.php HTTP/1.1" 405 53 "-" "Mozilla/5.0 (X11; Linux i686; rv:2.0.1) Gecko/20100101 Firefox/4.0.1" "-"

PHP module compilation error – libtool: Version mismatch error

If you happen to get this error trying to build your own a PHP module (probably, because you need a newer version than the included one in the disto you use and because it is fairly easy):

libtool: Version mismatch error.  This is libtool 2.4.6, but the
libtool: definition of this LT_INIT comes from an older release.
libtool: You should recreate aclocal.m4 with macros from libtool 2.4.6
libtool: and run autoconf again.
make: *** [Makefile:181: geoip.lo] Error 63

Here is what you can do to recreate the configuration files for the build process:

phpize
aclocal
libtoolize --force
autoheader
autoconf
./configure
make

This sequence of commands (probably without the phpize, because it is PHP specific) could save you in similar situations with similar error in other source code not related to PHP.
Keep on reading!

Persistent connections for PHP sessions stored using Memecached

If you have a highly loaded PHP application server you probably came to conclusion to use memcached to store the PHP sessions, because files are too slow and generate many IOs. And when the session are enabled to be stored in memcached server the server could be overloaded with so many connections to the memcached instance(s) that the server could delay the creation of new connections to the memcached server and the server is in trouble even more than before with the file stored sessions.
The solution is to use persistent connections to the memcached server, so when a connection to the memcached is needed it will check to reuse an existing idle connection stored in a pool of connections so no new connection is created each time PHP needs something from the cache like the sessions. In fact PHP accesses sessions from the cache at least once for every request to the server and it could generate a pretty big number of opened connections.

On top of that there are two PHP modules, which offer objects or functions to use memcached server cache in your PHP code. The old module is called “memcache” (link) and the new one is “memcached” (link) – just to note these are the names of the PHP modules not to be mistaken by the server caching system “memcached”.

To configure the php-fpm or mod_php to store sessions in memcached caching server:

  1. use PHP “memcached”, this is the new and better supported module for using a memcached cache server. It supports the newer versions of PHP like 7+.
  2. use the following configuration added to your php.ini or the module ini file included in your php.ini (it really depends on your configuration, but if you are not sure put phpinfo() function in a PHP file and load through your web server – you’ll see the physical location of your php.ini file);
session.save_path = "PERSISTENT=1 localhost:11212"

Replace localhost with the server IP or leave it if the memcached server is on the localhost. This single configuration could decrease the usage of opened sockets from several tens of thousands (literally 30 000 – 100 000 and above) to couple of hundreds, which could have a great impact on system performance! (You’ll see it like a system usage time in your server graphs…)

*Worth mentioning the PHP configuration (php.ini file) must be edited to use memcached server for storing sessions:

session.save_handler = memcached