Настройка VPS на максимальную производительность нужна для обеспечения полного использования ресурсов виртуального сервера, работы быстрых и функциональных сайтов, интернет магазинов и высоконагруженых сервисов.

Рассмотрим настройку VPS сервера c Ubuntu Server 20.04 на максимальную производительность. Настройки актуальны (с некоторыми оговорками) для других Linux серверов со связкой Open LiteSpeed + CyberPanel, в том числе, с Apache + Nginx, PHP-FPM + Nginx.

Следует понимать, что без адаптации и дополнительных настроек web-серверов отличных от OLS эффект от настроек VPS будет несколько скромнее. То же самое касается выделенных серверов: настройка VPS на максимальную производительность и настройка выделенного сервера — разные задачи требующие индивидуального подхода.

Настройка VPS на максимальную производительность (на базе Ubuntu Server 20.04)

Настройка VPS на максимальную производительность — комплекс действий направленных на обеспечение не только «экстремальной» производительности VPS, но и обеспечение стабильности и безопасности VPS, web-сервера, быстрой и бесперебойной работы сайтов, сохранности и конфиденциальности вашей информации.

Настройка VPS на максимальную производительность включает несколько этапов:

• Установка самого нового ядра Linux, настройка параметров ядра
• Настройка важных файлов конфигурации Linux сервера
• Обновление сервера баз данных MariaDB и первоначальная настрока
• Обновление и настройка PHP необходимых вам версий
• Настройка Redis и Memcache(d)
• Настройка файловой системы Ext4 на максимальную производительность
• Настройка сетевого интерфейса и стека протокола IPv4

Установка новой версии ядра Linux на VPS Ubuntu

Обновление операционной системы Ubuntu Server

/* Проверка места на диске */

df -h

/* Обновление Ubuntu 20.04 */

apt update && apt upgrade -y

apt autoremove

apt autoclean

Установите скрипт обновления ядра сервера:

Установка скрипта обновленяя ядра Linux

wget https://raw.githubusercontent.com/pimlie/ubuntu-mainline-kernel.sh/master/ubuntu-mainline-kernel.sh

chmod +x ubuntu-mainline-kernel.sh

sudo mv ubuntu-mainline-kernel.sh /usr/local/bin/

Проверьте какая версия ядра установлена на VPS, какая новая версия ядра Linux доступна. Установите новое ядро Linux:

Установка нового ядра Ubutu Server

/* Проверка версии установленного ядра Linux */

uname -r

/* Проверка последней доступной версии ядра Ubuntu linux */

ubuntu-mainline-kernel.sh -c

/* Установка новой версии ядра на VPS Ubuntu Server */

ubuntu-mainline-kernel.sh -i

Ошибка «Abort, the amd64 build has not succeeded » исправляется установкой ранней версии ядра. Например, последняя версия ядра Linux v5.18.5. Установим версию v5.18.4:

Установка определеной версии ядра Linux

ubuntu-mainline-kernel.sh -i v5.18.4

Перезагрузите VPS и убедитесь что установлено новое ядро:

Провеока версии ядра Linux

reboot

uname -r

Настройка параметров ядра Linux и операционной системы Ubuntu 20.04 Server

Добавление модулей ядра Linux

Перед началом работ убедитесь, что на VPS достаточно свободного дискового пространства. Обновим ОС Ubuntu, удалим старые пакеты и очистим кэш пакетного менеджера Apt:

Для настройки файловой системы, подсистемы памяти и сети на максимальную производительность VPS нам потребуется внести ряд изменений в настройки ядра.

Добавление модуля ядра Linux TCP_BBR

‎BBR («‎‎B‎‎ottleneck ‎‎B‎‎andwidth and‎‎ R‎‎ound-trip propagation time») — это новый алгоритм контроля нагрузки сети, разработанный в Google. Алгоритмы контроля анализируют состояние сетевого стека, определяют порядок, очередность и скорость обмена данными через сетевой интерфейс.‎

Определим, установлен ли модуль ядра Linux tcp_bbr:

Проверка доступности протокола BBR

modinfo tcp_bbr

Если модуль ядра tcp_bbr активен, то увидим следующую информацию:

Информация о протоколе BBR

filename:       /lib/modules/5.18.4-051804-generic/kernel/net/ipv4/tcp_bbr.ko

description:    TCP BBR (Bottleneck Bandwidth and RTT)

license:        Dual BSD/GPL

author:         Soheil Hassas Yeganeh soheil@google.com

author:         Yuchung Cheng ycheng@google.com

author:         Neal Cardwell ncardwell@google.com

author:         Van Jacobson vanj@google.com

srcversion:     57B6BEF8B52C7C9E23030B4

depends:        

retpoline:      Y

intree:         Y

name:           tcp_bbr

vermagic:       5.18.4-051804-generic SMP preempt mod_unload modversions

sig_id:         PKCS#7

signer:         Build time autogenerated kernel key

sig_key:        2C:7E:56:6C:F0:4A:12:66:F4:C2:04:27:E5:DA:65:46:34:E3:07

sig_hashalgo:   sha512

signature:      64:1F:B5:42:E2:FF:EE:83:DD:A5:BA:9E:DE:3A:31:35:71:EB:3D:ED:

                …

                3D:5C:D6:67:47:19:BB:25:20:60:0B:24

В противном случае (в 99% из 100), если модуль ядра Linux tcp_bbr не доступен получим сообщение о том, что модуль не найден: modprobe: FATAL: Module tcp_bbr not found in directory /lib/modules/5.18.4-051804-generic.

Установка tcp_bbr:

Включение модуля ядра tcp_bbr

echo ‘net.ipv4.tcp_congestion_control=bbr’ >> /etc/sysctl.d/99-sysctl.conf

sysctl net.ipv4.tcp_available_congestion_control

modprobe tcp_bbr

sysctl net.ipv4.tcp_available_congestion_control

sudo sysctl -p

sysctl net.ipv4.tcp_congestion_control

sysctl net.ipv4.tcp_available_congestion_control

Снова проверим наличие поддержки ядром Linux протокола BBR:

Поддержка протокола BBR ядром Linux

kmod list | grep tcp_bbr

/* или */

modinfo tcp_bbr

Теперь вы должны увидеть информацию о загруженном модуле tcp_bbr. Это далеко не все, что необходимо для использования всех преимуществ этой технологии. Остальные ньюансы мы рассмотрим когда перейдем к настройке сети VPS на максимальную производительность.

Дополнительные настройки ядра Linux для максимального быстродействия VPS

Для обеспечения высокой производительности файловой системы VPS сервера, веб-сервера и сервера баз данных выполним несколько настроек ядра.

Обеспечение правильного использования O_DIRECT и O_DSYNC

В файловой системе Linux есть условия, которые требуют «исправлений» ядра для поддержки запросов ввода-вывода (актуально для всех версий серверов баз данных SQL включая MariaDB).

Если запрос не соответствует ожидаемым критериям, создается новый буфер (буферы) ядра, копируются данные, блокируется передача устройств с использованием временных буферов, а затем освобождается временный буфер.

Используя трассировку файловой системы Linux, вы можете подтвердить, что прямой запрос ввода-вывода выровнен по правильной границе памяти для передачи DMA, смещение начинается на границе блочного устройства и т. д., чтобы избежать временных блокировок и неоправданных буферизованных действий.

Включение трассировки (xfs, ext4, трассировка блочных устройств):

Трассировка доступа Ext4 и блочных устройств на уровне ядра

echo 1 > /sys/kernel/debug/tracing/events/block/enable

echo 1 > /sys/kernel/debug/tracing/events/ext4/enable

cat /sys/kernel/debug/tracing/trace

sysctl kernel.core_pattern=core.%p kernel.core_uses_pid=0

mkdir /tmp/corefiles

chmod 777 /tmp/corefiles

echo /tmp/corefiles/core > /proc/sys/kernel/core_pattern

echo 1 > /proc/sys/kernel/core_uses_pid

Некоторые настройки ядра выполним в /etc/sysctl.conf. Хорошая документация по настройке ядра есть на www.kernel.org.

Изменение файлов конфигурации ОС Ubuntu Server для максимальной производительности VPS, MariaDB и Open LiteSpeed

Для обеспечения максимальной производительности и надежности VPS требуется внести ряд изменений и исправлений в файлы конфигурации сервера. Большинство конфигурационных файлов находится в /etc.

Настройка параметров sysctl.conf для максимальной производительности VPS

Sysctl.conf файл конфигурации системной утилиты sysctl управляющей параметрами ядра Linux «на лету». Позволяет читать и настраивать параметры ядра систем на ОС Linux.

Редактируем файл sysctl.conf:

Настройка VPS на максимальную производительность — sysctl.conf

/* Открываем sysctl.conf в редакторе */

mcedit /etc/sysctl.conf

/* Вносим изменения в /etc/sysctl.conf — добавляем в конец файла */

net.ipv4.conf.all.arp_notify = 1

net.ipv4.tcp_congestion_control = bbr

fs.aio-max-nr = 1048576

fs.dir-notify-enable = 1

fs.epoll.max_user_watches = 51660308

fs.fanotify.max_queued_events = 16384

fs.fanotify.max_user_groups = 128

fs.fanotify.max_user_marks = 15755

fs.file-max = 25224638

fs.inotify.max_queued_events = 16384

fs.inotify.max_user_instances = 128

fs.inotify.max_user_watches = 8192

fs.lease-break-time = 45

fs.leases-enable = 1

fs.mount-max = 100000

fs.mqueue.msg_default = 10

fs.mqueue.msg_max = 10

fs.mqueue.msgsize_default = 8192

fs.mqueue.msgsize_max = 8192

fs.mqueue.queues_max = 256

fs.nr_open = 1048576

fs.pipe-max-size = 1048576

fs.pipe-user-pages-hard = 0

fs.pipe-user-pages-soft = 16384

fs.protected_fifos = 1

fs.protected_hardlinks = 1

fs.protected_regular = 2

fs.protected_symlinks = 1

fs.suid_dumpable = 0

fs.verity.require_signatures = 0

vm.swappiness = 1

vm.overcommit_memory = 1

vm.vfs_cache_pressure = 50

vm.dirty_background_bytes = 4194304

vm.dirty_bytes = 4194304

vm.dirty_background_ratio = 5

vm.dirty_ratio = 10

vm.dirty_expire_centisecs = 500

vm.dirty_writeback_centisecs = 100

vm.max_map_count = 1600000

kernel.numa_balancing = 0

kernel.msgmnb = 65536

kernel.msgmax = 65536

kernel.shmmax = 68719476736

kernel.shmall = 4294967296

kernel.core_pattern = /tmp/corefiles/core

kernel.core_uses_pid = 1

net.core.default_qdisc = fq

net.core.default_qdisc=pfifo_fast

net.core.netdev_budget = 300

net.core.optmem_max = 65536

net.core.somaxconn = 8192

net.core.netdev_max_backlog = 16384

net.core.rmem_default = 262144

net.core.rmem_max = 4194304

net.core.wmem_default = 65536

net.core.wmem_max = 16777216

net.ipv4.conf.all.accept_redirects = 0

net.ipv4.conf.default.accept_redirects = 0

net.ipv4.conf.all.secure_redirects = 0

net.ipv4.conf.default.secure_redirects = 0

net.ipv6.conf.all.accept_redirects = 0

net.ipv6.conf.default.accept_redirects = 0

net.ipv4.conf.all.send_redirects = 0

net.ipv4.conf.default.send_redirects = 0

net.ipv4.conf.all.arp_ignore = 1

net.ipv4.conf.all.accept_source_route = 0

net.ipv4.conf.all.rp_filter = 1

net.ipv4.conf.default.arp_ignore = 1

net.ipv4.conf.default.rp_filter = 1

net.ipv4.conf.default.accept_source_route = 0

net.ipv4.conf.lo.accept_source_route = 0

net.ipv4.conf.lo.rp_filter = 1

net.ipv4.conf.eth0.accept_source_route = 0

net.ipv4.conf.eth0.rp_filter = 1

net.ipv4.udp_mem = 8388608 12582912 16777216

net.ipv4.udp_rmem_min = 16384

net.ipv4.udp_wmem_min = 16384

net.ipv4.route.flush = 1

net.ipv4.ip_local_port_range = 1024 65535

net.ipv4.ip_forward = 0

net.ipv4.ip_no_pmtu_disc = 0

net.ipv4.tcp_ecn = 1

net.ipv4.tcp_mtu_probing = 1

net.ipv4.tcp_mem = 8388608 12582912 16777216

net.ipv4.tcp_rmem = 8192 87380 8388608

net.ipv4.tcp_wmem = 8192 87380 8388608

net.ipv4.tcp_timestamps = 1

net.ipv4.tcp_window_scaling = 1

net.ipv4.tcp_syncookies = 0

net.ipv4.tcp_fastopen = 3

net.ipv4.tcp_fin_timeout = 30

net.ipv4.tcp_fack = 0

net.ipv4.tcp_sack = 0

net.ipv4.tcp_dsack = 1

net.ipv4.tcp_max_syn_backlog = 65536

net.ipv4.tcp_slow_start_after_idle = 0

net.ipv4.tcp_keepalive_time = 1800

net.ipv4.tcp_keepalive_probes = 5

net.ipv4.tcp_keepalive_intvl = 15

net.ipv4.tcp_tw_reuse = 1

net.ipv4.tcp_max_tw_buckets = 1000000

net.ipv4.tcp_max_orphans = 65536

net.ipv4.tcp_synack_retries = 1

net.ipv4.tcp_orphan_retries = 0

net.ipv4.tcp_no_metrics_save = 1

net.ipv4.tcp_rfc1337 = 1

net.ipv4.icmp_echo_ignore_broadcasts = 1

net.ipv4.icmp_ignore_bogus_error_responses = 1

Применение изменений в файле sysctl.conf:

Обновление конфигурации утилиты sysctl

1

sysctl -p

Проверьте вывод утилиты в консоли на предмет ошибок и исправьте при необходимости некорректные параметры. Теперь реализована полная поддержка экспериментального протокола BBR1, настроены параметры ядра отвечающие за файловую систему, стек протокола IP, виртуальную память.

Кроме того, решили некоторые вопросы стабильности, производительности, а главное, безопасности VPS, операционной системы, стека протокола IP2. Полная документация доступна https://www.kernel.org/doc/Documentation/sysctl/.

Современные версии Ubuntu Server по умолчанию имеют нормально настроенные параметры sysctl.conf. Стандартные настройки обеспечивают стабильное функционирование VPS, но не всегда обеспечивают максимальную производительность.

Если у вас пробелы в теории, то помочь может только практика и тестирование. В сети вы можете найти сотни конфигураций sysctl.conf, но вероятность того, что какая то конфигурация подойдет вашему VPS исчезающе мала.

Пример: Во всех руководствах описываются два связанных параметра отвечающих за работу BBR.

Параметры отвечающие за работу BBR

net.ipv4.tcp_congestion_control = bbr

net.core.default_qdisc = fq

Но ни в одном руководстве нет ни слова, о настройке ядра для второго параметра (без чего невозможно достигнуть максимума пропускной способности сети), и тем более, ни слова о том, когда использовать fq, а когда CUBIC будет предпочтительней. pfifo_fast вообще не упоминается, хотя это единственное решение позволяющее избежать блокировки и потери пакетов.

Использование net.core.default_qdisc=pfifo_fast

tc -s qdisc show dev eth0

qdisc pfifo_fast 0: root refcnt 2 bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1

Sent 19259793 bytes 69622 pkt (dropped 0, overlimits 0 requeues 0)

backlog 0b 0p requeues 0

На самом деле, настройка конфигурационных файлов Linux серверов не «пляски с бубном» как может показаться на первый взгляд, а комплекс мероприятий основанных на знании сетевого стека, параметров ядра и особенностей используемой файловой системы, сервера баз данных и веб-сервера.

Найти вменяемую документацию по настройке серверов практически невозможно, но к счастью необходимую информацию можно получить изучая исходный код ядра, утилит и модулей дистрибутивов Linux.

Настройка VPS на максимальную производительность — limits.conf

Очень важный для производительности VPS, сервера баз данных, PHP доступен в etc/security/limits.conf. ‎Модуль ‎‎pam_limits.so‎‎ применяет ограничения ulimit, устанавливает приоритет и количество одновременных сеансов входа в систему и сеансов пользователей (с точки зрения Linux, например msql такой же пользователь как root…).

Настройка /etc/security/limits.conf

/* Открываем файл конфигурации limits.conf */

mcedit /etc/security/limits.conf

/* Вносим изменения. Удалите содержимое файла и вставьте строки ниже */

*               soft    core            10000

root            hard    core            100000

*               hard    rss             10000

root soft nofile unlimited

root hard nofile unlimited

mysql soft nofile unlimited

mysql hard nofile unlimited

mysql soft nproc unlimited

mysql hard nproc unlimited

mysql soft core  unlimited

mysql hard core  unlimited

*   —    nofile  1048576

root — memlock unlimited

*                soft    nofile          130000

*                hard    nofile          130000

*                soft    nproc           130000

*                hard    nproc           130000

root             soft    nproc           130000

root             hard    nproc           130000

Настройка rc.local

Этот файл по неизвестным причинам не пользуется популярностью у системных администраторов. С его помощью можно настроить многие параметры VPS. Приведите файл rc.local к такому виду:

Настройка файла /etc/rc.local

/* Редактирование файла /etc/rc.local */

mcedit /etc/rc.local

/* Содержимое файла /etc/rc.local */

!/bin/bash

echo 1000000 > /proc/sys/kernel/pid_max

echo 1 > /sys/kernel/mm/ksm/run

echo never > /sys/kernel/mm/transparent_hugepage/enabled

echo 1 > /sys/kernel/debug/tracing/events/block/enable

echo 1 > /sys/kernel/debug/tracing/events/ext4/enable

echo /tmp/corefiles/core > /proc/sys/kernel/core_pattern

echo 1 > /proc/sys/kernel/core_uses_pid

echo 2 > /sys/module/tcp_cubic/parameters/hystart_detect

echo 32768 > /proc/sys/net/core/rps_sock_flow_entries

nohup watchdog lsws > /dev/null 2>&1 &

nohup watchdog mariadb > /dev/null 2>&1 &

Хотя rc.local считается «устаревшим», это удобный инструмент для запуска необходимых скриптов. Проверьте, настроена ли поддержка /etc/rc.local:

Поддержка /etc/rc.local

systemctl status rc-local.service

/* Если не загружен */

sudo chmod -v +x /etc/rc.local

systemctl enable rc-local.service

systemctl start rc-local.service

Настройка MariaDB server на максимальную производительность

Подавляющее большинство сайтов и веб-сервисов используют SQL сервер для хранения данных. Это может быть MS SQL, PostgreSQL, Percona, MariaDB server, их аналоги или форки.

Используем MariaDB server как наиболее быстрый и стабильный в работе. Сервер баз данных уже установлен. Обновим до последней стабильной версии и настроим производительность, а так же примем некоторые меры для обеспечения безопасности сервера баз данных.

Некоторые настройки влияющие на производительность MariaDB сделали ранее в настройках sysctl.conf и limits.conf.

Установка последней стабильной версии MariaDB server

Проверим текущую версию сервера баз данных:

Проверка установленной версии MariaDB server

mysql -V

Установлена версия 10.3.34-MariaDB:

Вывод команды mysql -V

mysql  Ver 15.1 Distrib 10.3.34-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2

Установим последнюю стабильную версию MariaDB:

Обновление MariaDB до последней версии

curl -sS https://downloads.mariadb.com/MariaDB/mariadb_repo_setup | sudo bash

apt update && apt upgrade -y

apt install  libmariadb-dev libmariadb3 mariadb-server

apt autoremove

apt autoclean

Снова прверьте версию MariaDB командой mysql -V. Версия должна быть не ниже 10.8.3 или более новой.

Проверка текущей версии сервера БД

mysql  Ver 15.1 Distrib 10.8.3-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2

Выполните обновление системных таблиц и схемы SQL:

Обновление таблиц системной базы данных MariaDB

mysql_upgrade

Не забывайте выполнять это действие после каждого обновления MariaDB server.

Безопасная установка MariaDB server

Вам понадобиться root пароль от mysql. Посмотрите файл /etc/cyberpanel/mysqlPassword:

Как посмотреть пароль root для MariaDB

cat /etc/cyberpanel/mysqlPassword

Выполним безопасную установку:

Безопасная установка MariaDB Server

/* Запуск скрипта безопасной установки */

mariadb-secure-installation

/* введите root пароль из /etc/cyberpanel/mysqlPassword */

NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MariaDB

      SERVERS IN PRODUCTION USE!  PLEASE READ EACH STEP CAREFULLY!

In order to log into MariaDB to secure it, we’ll need the current

password for the root user. If you’ve just installed MariaDB, and

haven’t set the root password yet, you should just press enter here.

Enter current password for root (enter for none): <ваш root пароль для mysql>

/* unix_socket authentication [Y/n] — отвечаем */

OK, successfully used password, moving on…

Setting the root password or using the unix_socket ensures that nobody

can log into the MariaDB root user without the proper authorisation.

You already have your root account protected, so you can safely answer ‘n’.

Switch to unix_socket authentication [Y/n] n

/*Оставляем прежний пароль root для mysql — отвечаем */

You already have your root account protected, so you can safely answer ‘n’.

Change the root password? [Y/n] n

/* Удаляем пользователей не имеющих паролей — отвечаем */

By default, a MariaDB installation has an anonymous user, allowing anyone

to log into MariaDB without having to have a user account created for

them.  This is intended only for testing, and to make the installation

go a bit smoother.  You should remove them before moving into a

production environment.

Remove anonymous users? [Y/n] y

/* Запрещаем доступ к серверу MariaDB по сети — отвечаем */

Normally, root should only be allowed to connect from ‘localhost’.  This

ensures that someone cannot guess at the root password from the network.

Disallow root login remotely? [Y/n] y

/* Удаляем тестовую базу данных — отвечаем */

By default, MariaDB comes with a database named ‘test’ that anyone can

access.  This is also intended only for testing, and should be removed

before moving into a production environment.

Remove test database and access to it? [Y/n] y

/* Обновляем права пользователей сервера баз данных — отвечаем */

Reloading the privilege tables will ensure that all changes made so far

will take effect immediately.

Reload privilege tables now? [Y/n] y

/* Результат успешной установки */

Cleaning up…

All done!  If you’ve completed all of the above steps, your MariaDB

installation should now be secure.

Thanks for using MariaDB!

Эта настройка практически не влияет на производительность MariaDB server, но обеспечивает безопасность, надежность и стабильность.

Установка и настройка Performance Schema

Несмотря на распространенное заблуждение Performance Schema не оказывает никакого влияния на производительность сервера баз данных.

Performance Schema — инструмент для мониторинга производительности сильно облегчает жизнь системным администраторам,архитекторам и инженерам баз данных и косвенно вам3. Статистика позволяет выявить «узкие» места в работе MariaDB и оперативно устранить их.

Редактируем файл настроек /etc/mysql/my.cnf:

Редактирование файла /etc/mysql/my.cnf

mcedit  /etc/mysql/my.cnf

Разрешаем использование Performance Schema:

Разрешение использования Performance Schema

[mysqld]

performance_schema=ON

performance-schema-instrument=’stage/%=ON’

performance-schema-consumer-events-stages-current=ON

performance-schema-consumer-events-stages-history=ON

performance-schema-consumer-events-stages-history-long=ON

Важно: вставьте эти строки в my.cnf перед секцией [client-server].

Сохраните файл и выполните команду:

Перезагрузка MariaDB

service mysql restart

Подключение к базе данных:

Подключение к MariaDB с root паролем

mysql -u root -p

Введите root пароль mysql. Если подключение к серверу баз данных успешно, вы увидите приглашение:

MariaDB server

Welcome to the MariaDB monitor.  Commands end with ; or \g.

Your MariaDB connection id is 35

Server version: 10.8.3-MariaDB-1:10.8.3+maria~focal mariadb.org binary distribution

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the current input statement.

MariaDB [(none)]>

Выполните последовательно две команды SQL:

Разрешение Performance Schema для MariaDB server

UPDATE performance_schema.setup_consumers SET ENABLED = ‘YES’;

UPDATE performance_schema.setup_instruments SET ENABLED = ‘YES’, TIMED = ‘YES’;

Результат успешного выполнения SQL запросов на активацию Performance Schema SQL сервера MariaDB:

Активация Performance Schema для MariaDB server

MariaDB [(none)]> UPDATE performance_schema.setup_consumers SET ENABLED = ‘YES’;

Query OK, 9 rows affected (0.002 sec)

Rows matched: 15  Changed: 9  Warnings: 0

MariaDB [(none)]> UPDATE performance_schema.setup_instruments SET ENABLED = ‘YES’, TIMED = ‘YES’;

Query OK, 557 rows affected (0.003 sec)

Rows matched: 989  Changed: 557  Warnings: 0

Performance Schema для MariaDB установлена. При корректной установке, выполнив команды:

Проверка установки Performance Schema в MariaDB

USE performance_schema

SHOW TABLES;

Вывод при наличии активной Performance Schema:

Таблицы Performance Schema в MariaDB

MariaDB [performance_schema]> SHOW TABLES;

+——————————————————+

| Tables_in_performance_schema                         |

+——————————————————+

| accounts                                             |

| cond_instances                                       |

| events_stages_current                                |

| events_stages_history                                |

| events_stages_history_long                           |

| events_stages_summary_by_account_by_event_name       |

| events_stages_summary_by_host_by_event_name          |

| events_stages_summary_by_thread_by_event_name        |

| events_stages_summary_by_user_by_event_name          |

| events_stages_summary_global_by_event_name           |

| events_statements_current                            |

| events_statements_history                            |

| events_statements_history_long                       |

| events_statements_summary_by_account_by_event_name   |

| events_statements_summary_by_digest                  |

| events_statements_summary_by_host_by_event_name      |

| events_statements_summary_by_program                 |

| events_statements_summary_by_thread_by_event_name    |

| events_statements_summary_by_user_by_event_name      |

| events_statements_summary_global_by_event_name       |

| events_transactions_current                          |

| events_transactions_history                          |

| events_transactions_history_long                     |

| events_transactions_summary_by_account_by_event_name |

| events_transactions_summary_by_host_by_event_name    |

| events_transactions_summary_by_thread_by_event_name  |

| events_transactions_summary_by_user_by_event_name    |

| events_transactions_summary_global_by_event_name     |

| events_waits_current                                 |

| events_waits_history                                 |

| events_waits_history_long                            |

| events_waits_summary_by_account_by_event_name        |

| events_waits_summary_by_host_by_event_name           |

| events_waits_summary_by_instance                     |

| events_waits_summary_by_thread_by_event_name         |

| events_waits_summary_by_user_by_event_name           |

| events_waits_summary_global_by_event_name            |

| file_instances                                       |

| file_summary_by_event_name                           |

| file_summary_by_instance                             |

| global_status                                        |

| host_cache                                           |

| hosts                                                |

| memory_summary_by_account_by_event_name              |

| memory_summary_by_host_by_event_name                 |

| memory_summary_by_thread_by_event_name               |

| memory_summary_by_user_by_event_name                 |

| memory_summary_global_by_event_name                  |

| metadata_locks                                       |

| mutex_instances                                      |

| objects_summary_global_by_type                       |

| performance_timers                                   |

| prepared_statements_instances                        |

| replication_applier_configuration                    |

| replication_applier_status                           |

| replication_applier_status_by_coordinator            |

| replication_applier_status_by_worker                 |

| replication_connection_configuration                 |

| rwlock_instances                                     |

| session_account_connect_attrs                        |

| session_connect_attrs                                |

| session_status                                       |

| setup_actors                                         |

| setup_consumers                                      |

| setup_instruments                                    |

| setup_objects                                        |

| setup_timers                                         |

| socket_instances                                     |

| socket_summary_by_event_name                         |

| socket_summary_by_instance                           |

| status_by_account                                    |

| status_by_host                                       |

| status_by_thread                                     |

| status_by_user                                       |

| table_handles                                        |

| table_io_waits_summary_by_index_usage                |

| table_io_waits_summary_by_table                      |

| table_lock_waits_summary_by_table                    |

| threads                                              |

| user_variables_by_thread                             |

| users                                                |

+——————————————————+

81 rows in set (0.001 sec)

MariaDB [performance_schema]>

Параметры my.cnf — настройка сервера баз данных на максимальную производительность

Пожалуй, самый трудный и спорный вопрос, это настройка конфигурации MariaDB server. Параметры в /etc/mysql/my.cnf непосредственно влияют на производительность сервера баз данных MariaDB.

Сколько системных администраторов, «guru» и псевдогуру, столько и мнений4. Примем за аксиому: есть два мнения — мое и неправильное. Отредактируйте my.cnf:

Редактирование файла /etc/mysql/my.cnf

mcedit /etc/mysql/my.cnf

Стандартная конфигурация my.cnf‎‎, которая работает на большинстве серверов и не вызывает проблем. Очистите файл my.cnf и внесите следующие настройки:

Параметры my.cnf для максимальной производительности

[mysqld]

Разрешение Performance Schema

performance_schema=ON

performance-schema-instrument=’stage/%=ON’

performance-schema-consumer-events-stages-current=ON

performance-schema-consumer-events-stages-history=ON

performance-schema-consumer-events-stages-history-long=ON

performance_schema_max_table_instances = 400

optimizer_search_depth = 0

transaction-isolation = READ-COMMITTED

character-set-server = utf8

collation-server = utf8_unicode_ci

init-connect = «SET NAMES utf8 COLLATE utf8_unicode_ci»

Разное, но важное

log-error = /var/log/mysql/error.log

tmpdir = /dev/shm

tmpdir = /tmp  # если мало оперативной памяти

local-infile=0

symbolic-links=0

skip-name-resolve

skip-external-locking = 1

skip-host-cache

skip-log-bin

sync_binlog = 0

skip_networking = ON

bind-address = 127.0.0.1

sysdate-is-now = 1

max_connections = 50 # смотрите на нагрузку сервера

wait_timeout = 60

interactive_timeout = 60

low-priority-updates = 1

max_allowed_packet = 128M

sql-mode= NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES # хорошо для тех, кто в танке

sql_mode = «»

Параметры кэширования запросов

open_files_limit = 130000

query_cache_size = 16M

table_open_cache = 4096

thread_cache_size = 16

key_buffer_size = 8M

thread_stack = 256K

join_buffer_size = 2M

sort_buffer_size = 2M

Временные таблицы

max_heap_table_size = 32M # отредактируйте под нужды своей бд

tmp_table_size = 32M # отредактируйте под нужды своей бд

Настройки InnoDB

innodb-strict-mode = 1

innodb_stats_on_metadata = 0

skip-innodb_doublewrite

innodb_temp_data_file_path = ibtmp1:128M:autoextend:max:1G

innodb_open_files = 130000

innodb_file_per_table

innodb_buffer_pool_size = 32M # отредактируйте под нужды своей бд

innodb_log_file_size = 8M # отредактируйте под нужды своей бд

innodb_flush_log_at_trx_commit = 0

innodb_flush_method = O_DIRECT_NO_FSYNC

innodb_use_native_aio = 0

[mysqldump]

quick

quote-names

max_allowed_packet = 128M

default-character-set = utf8

[mysql]

no-auto-rehash

[isamchk]

key_buffer = 16M

[mysqld_safe]

log-error = /var/log/mysql/error.log

pid-file = /var/run/mariadb/mariadb.pid

Вы должны понимать, что это «стартовая» конфигурация mysql. Когда вы создадите свой сайт или перенесете существующий, то потребуется обязательная правка некотоых параметров под реальную базу данных. Некоторые важные параметры выделены комментариями в коде выше.

При настройке MariaDB необходимо учитывать:

• Количество доступной оперативной и виртуальной памяти
• Свободное место на диске
• Потребности сайта(сайтов) или ваших сервисов

Если у вас очень большой проект то лучшим решением будет вынести сервер баз данных на отдельный VPS. Понятно, что некоторые настройки будут другими, но суть вы уже поняли.

Настройка systemd сервиса mysqld

Некоторые критические настройки MariaDB вынесены за рамки my.cnf и выполняются в файле конфигурации @mysqld.service для systemd. Откроем файл конфигурации mysqld и отредактируем несколько параметров:

Правильные настройки /etc/systemd/system/mysqld.service

mcedit /etc/systemd/system/mysqld.service

/* Редактируем настройки mysqld.service */

Number of files limit. previously [mysqld_safe] open-files-limit

LimitNOFILE=130000

Maximium core size. previously [mysqld_safe] core-file-size

LimitCore=infinity

Nice priority. previously [mysqld_safe] nice

Nice=-10

Выполните следующие команды чтобы изменения вступили в силу:

Обновляем конфигурацию сервисов systemd для mysql

systemctl daemon-reload

service mysql restart

Основная настройка сервера баз данных MariaDB выполняется с помощь конфигурационных файлов my.cnf, limits.conf, sysctl.conf, mysqld.service. Это главное, что вам надо знать о настройке сервера баз данных на максимальную производительность.

Скорость, стабильность, «отзывчивость» сервера баз данных MariaDB (как и любого SQL сервера) напрямую зависят от количества и производительности CPU(ядер и потоков), доступной оперативной и виртуальной памяти, производительности файловой системы и конечно от правильных настроек5.

Замена memcace(d) на LSMCD

Кроме MariaDB, MSSQL(или подобных) для кэширования данных и ускорения сайтов и сервисов широко используются NoSQL базы данных:

• Redis
• Memcache(d)
• Varnish
• Opcache (механизм кэширования PHP)

В каждом конкретном случае, нужно использовать наиболее подходящий инструмент кэширования, а иногда и связку из нескольких. Многие плагины кэширования попуряпных CMS умеют с ними работать.

Плагин кэширования для Open LiteSpeed доступен для CMS WordPress и некоторых других. Он поддерживает Redis и Memcahe(d). Это лучший плагин кэширования для OLS.

Использование Memcahed и Redis

Для LiteSpeed и Open LiteSpeed серверов разработан улучшенный механизм memcache(d) — LSMCD избавленный от недостатков стандартного memcache и получивший возможности и достоинства Varnish.

LiteSpeed Memcached — это memcache-совместимый сервер кэша LiteSpeed, поддерживающий репликацию высокой доступности. Его производительность и интерфейс похожи на популярный Memcached. В отличие от Memcached, данные кэша являются постоянными, сохраняя все данные кэша при обновлении и при сбое сервера.‎

Установка LSMCD:

Установка LSMCD вместо Memcache(d)

apt-get install build-essential zlib1g-dev libexpat1-dev openssl libsasl2-dev

wget https://github.com/litespeedtech/lsmcd/archive/master.zip

unzip master.zip

cd $(ls -1d lsmcd-*/ | tail -1)

./fixtimestamp.sh

./configure CFLAGS=» -O3″ CXXFLAGS=» -O3″

make

cd dist

./install.sh

Отредактируйте файл конфигурации LSMCD:

Настройка конфигурации LSMCD

mcedit /usr/local/lsmcd/conf/node.conf

/* Удалите содержимое файла и вставьте данные ниже */

Repl.HeartBeatReq=30

Repl.HeartBeatRetry=3000

Repl.MaxTidPacket=2048000

Repl.GzipStream=YES

Repl.LbAddrs=127.0.0.1:12340

Repl.ListenSvrAddr=127.0.0.1:12340

REPL.DispatchAddr=127.0.0.1:5501

RepldSockPath=/tmp/repld.usock

CACHED.PRIADDR=127.0.0.1:11000

CACHED.ADDR=127.0.0.1:11211

CACHED.ADDR=UDS:///tmp/lsmcd.sock

default is 8, it can be bigger depending on cache data amount

Cached.Slices=8

Cached.Slice.Priority.0=100

Cached.Slice.Priority.1=100

Cached.Slice.Priority.2=100

Cached.Slice.Priority.3=100

Cached.Slice.Priority.4=100

Cached.Slice.Priority.5=100

Cached.Slice.Priority.6=100

Cached.Slice.Priority.7=100

Cached.ShmDir=/dev/shm/lsmcd

Cached.UseSasl=false

Cached.DataByUser=true

Cached.Anonymous=true

Cached.SaslDB=/etc/sasllsmcd

this is the global setting, no need to have per slice configuration.

User=nobody

Group=nobody

depends CPU core

CachedProcCnt=4

CachedSockPath=/tmp/cached.usock.

TmpDir=/tmp/lsmcd

LogLevel=notice

LogLevel=dbg_medium

LogFile=/tmp/lsmcd.log

Подробная документация по использованию и настройке LSMCD — https://www.litespeedtech.com/support/wiki/doku.php/litespeed_wiki:lsmcd:configuration

Запустите сервер с новыми параметрами:

Запуск LSMCD

service lsmcd stop

service lsmcd start

/* Проверка работы сервера LSMCD */

service lsmcd status

Удачный запуск сервера LSMCD:

Удачный запуск LSMCD

service lsmcd status

● lsmcd.service — LiteSpeed LSMCD Daemon

     Loaded: loaded (/etc/systemd/system/lsmcd.service; enabled; vendor preset: enabled)

     Active: active (running) since Thu 2022-06-30 18:09:44 MSK; 13h ago

    Process: 3347 ExecStart=/usr/local/lsmcd/bin/lsmcdctrl start (code=exited, status=0/SUCCESS)

   Main PID: 3365 (lsmcd)

     CGroup: /system.slice/lsmcd.service

             ├─3365 /usr/local/lsmcd/bin/lsmcd -f /usr/local/lsmcd/conf/node.conf

             ├─3367 /usr/local/lsmcd/bin/lsmcd

             ├─3368 /usr/local/lsmcd/bin/lsmcd

             ├─3369 /usr/local/lsmcd/bin/lsmcd

             ├─3370 /usr/local/lsmcd/bin/lsmcd

             └─3371 /usr/local/lsmcd/bin/lsmcd

Jun 30 18:09:42 Server741001 systemd[1]: Starting LiteSpeed LSMCD Daemon…

Jun 30 18:09:44 Server741001 lsmcdctrl[3347]: [OK] lsmcd: pid=3365.

Jun 30 18:09:44 Server741001 lsmcdctrl[3347]: Final rc:  0

Jun 30 18:09:44 Server741001 systemd[1]: Started LiteSpeed LSMCD Daemon.

Установка и настройка LiteSpeed Memcached (LSMCD) закончена. LSMCD не влияет на производительность VPS, но может существенно ускорить работу сайтов. Как использовать LSMCD зависит от ваших знаний и фантазии. К этому вопросу мы еще вернемся.

Настройка Redis

Несмотря на все старания разработчиков Ubuntu не испортить «маму» Debian это им не всегда удается. Например, сервер Redis устанавливается и работает, но в суровой реальности пользоваться им невозможно. Добавьте в /etc/sysctl.conf если не сделали ранее:

Исправление проблемы redis

mcedit /etc/sysctl.conf

vm.overcommit_memory = 1 # исправление проблемы redis

Выполните команду sysctl -p и перезагрузите redis сервер: service redis restart.

Настройка PHP версий 7.X — 8.X на максимальную производительность

Для Open LiteSpeed доступны версии PHP от 7.0 до 8.1 включительно6. Причем OLS использует LSPHP — оптимизированную сборку PHP для работы с сервисами LiteSpeed через LiteSpeed SAPI. LSPHP запускается как самостоятельный процесс и имеет отдельный исполняемый файл, который используется как обычный исполняемый файл командной строки для запуска скриптов PHP.

Настройка LSPHP осуществляется с помощью php.ini индивидуально для каждой версии. Кроме того, параметры php можно переопределить на уровне сайта в WebAdmin.  В LSPHP реализована полная поддержка файла .htaccess без использования расширения PHP htscanner.

Настройка php.ini

Файл конфигурации php.ini для каждой версии PHP находится в /usr/local/lsws/lsphpXY/etc/php/X.Y/litespeed/php.ini. Например, для системной PHP7.4 используемой OLS по умолчанию(можно переопределить) файл php.ini будет находиться по адресу: /usr/local/lsws/lsphp74/etc/php/7.4/litespeed/php.ini. Редактируем:

Настройка php.ini для Open LiteSpeed

mcedit/usr/local/lsws/lsphp74/etc/php/7.4/litespeed/php.ini

/* Вносим изменения */

max_execution_time = 30 #можно увеличить при необходимости

max_input_time = 60 #можно увеличить при необходимости

max_input_vars = 3000

memory_limit = 256M #можно увеличить при необходимости

post_max_size = 80M #можно увеличить при необходимости

upload_max_filesize = 60M #можно увеличить при необходимости

/* Секция [PCRE] */

pcre.jit=1

/* Секция [opcache] — раскоментируем некоторые параметры и установим новые значения.

Внимание: использовать осторожно. Opcache не всегда «must-have», особенно для WordPress */

opcache.enable=1

opcache.enable_cli=0

opcache.memory_consumption=256

opcache.interned_strings_buffer=32

opcache.max_accelerated_files=100000

opcache.max_wasted_percentage=5

/* Добавим в секция [opcache] опции jit.

Внимание: используйте осторожно, возможно получите недиагностируемые ошибки 503 */

opcache.jit_buffer_size=128M

opcache.jit=tracing

Повторите эти настройки для всех необходимых версий PHP и перезагрузите сервер:

Перезагрузка VPS

reboot

На этом будем считать что настройка VPS на максимальную производительность завершена. На самом деле, этот процес непрерывный. По мере развития вашего проекта, добавления новых сайтов некотоые параметры PHP, MariaDB и.т.п. будут нуждаться в корректировке.

Мы оставили «за скобками» тюнинг файловой системы VPS и некоторые настройки сети. Желающие пройти квест с настройками файловой системы7 могут найти в интернет раннюю версию этой статьи — ее не скопировал только ленивый.

Вы преодолели уже почти 20% пути. Нас ждет CyberPanel, WebAdmin, настройка Open LiteSpeed Cache, настройка hosts(сайтов) на максимальную производительность, рассмотрим проблемы безопасности VPS и сайтов и займемся их устранением…

П римечания:

1. На подходе версия протокола BBR2. Но из за ошибок и некоторых проблем безопасности использовать в реальных проектах пока не стоит.
2. Настройка VPS на максимальную производительность редактированием параметров в файле sysctl.conf очень мощный, но не всегда безопасный инструмент. Мы отредактировали лишь чуть больше сотни параметров критически важных для максимального быстродействия VPS.

Описать все возможности sysctl в рамках одной статьи невозможно, да и не нужно. Иначе вам понадобится несколько суток на чтение и возможно не хватит жизни чтобы разобраться во всех ньюансах. Надеюсь, что самые «упертые» все же смогут дочитать статью до конца.

Кроме сильного влияния на производительность VPS стоит отметить, что изменение одних параметров в файле sysctl.conf может кардинально повлиять на эффективность других параметров ядра и Linux в целом. Мы можем получить как сильный прирост производительности, так и ее деградацию.

3. Инстумент мониторинга mysqltuner активно использует статистику Performance Schema для генерации рекомендаций настройки и тюнинга SQL server.
4. И все они неправильные, или условно годные для частных случаев.А если учесть, что в интернете настройке sql серверов посвящены десятки тысяч статей различной степени бесполезности, зачастую просто устаревшие и вводящие в заблуждение не только новичков, то актуальная информация на тему настройки сервера баз данных на максимальную производительность должна быть востребована.
5. Еще раз хочу обратить внимание, что настройка MariaDB на максимальную производительность для VPS, равно как и настройка VPS на максимальную производительность отличается (иногда кардинально) от настроек выделенного сервера.

Помните, что мы рассматриваем частный случай — настройку VPS. Универсального рецепта нет и не может быть.

6. Вы можете при необходимости скомпилировать и установить версии PHP 5.X используя WebAdmin. Но необходимость этого шага сомнительна. Проще переделать скрипты PHP5.4 — 5.6 в PHP7.2 — 7.4.
7. По большему счету, тюнинг файловой системы теперь не имеет особого смысла. Ext4 и ее поддержку в новых ядрах довели до ума, поэтому нет никакого смысла гоняться за парой процентов прироста производительности.