Перейти к основному содержимому
Версия: v2.2.x

Оптимизация MariaDB

Настройка MariaDB

Одной из причин медленной работы AxelNAC может быть недостаточная производительность MariaDB.

Чтобы ее настроить выполните следующие действия:

Шаг 1. Проверьте загрузку системы с помощью команды:

uptime
11:36:37 up 235 days, 1:21, 1 user, load average: 1.25, 1.05, 0.79

Шаг 2. Установите утилиту iostat.

Шаг 3. Проверьте iostat и загрузку процессора с помощью команд:

iostat 5
avg-cpu: %user %nice %sys %iowait %idle
0.60 0.00 3.20 20.20 76.00
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
cciss/c0d0 32.40 0.00 1560.00 0 7800
avg-cpu: %user %nice %sys %iowait %idle
0.60 0.00 2.20 9.20 88.00
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
cciss/c0d0 7.80 0.00 73.60 0 368
avg-cpu: %user %nice %sys %iowait %idle
0.60 0.00 1.80 23.80 73.80
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
cciss/c0d0 31.40 0.00 1427.20 0 7136
avg-cpu: %user %nice %sys %iowait %idle
0.60 0.00 2.40 18.16 78.84
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
cciss/c0d0 27.94 0.00 1173.65 0 5880

В приведенном примере среднее значение нагрузки составляет 1,25, а пиковое значение iowait достигает 20% — что говорит о высокой загрузке. Если iowait низкий, но MariaDB занимает более 50% процессора — такое значение также говорит о высокой загрузке базы данных.

Шаг 4. Проверьте установку MariaDB на наличие следующих переменных:

MariaDB> show variables;
| innodb_additional_mem_pool_size | 1048576 |
| innodb_autoextend_increment | 8 | |
| innodb_buffer_pool_awe_mem_mb | 0 | |
| innodb_buffer_pool_size | 8388608 |

AxelNAC в значительной степени зависит от InnoDB, поэтому следует увеличить размер буферного пула buffer_pool относительно значений по умолчанию.

Шаг 5. В веб-интерфейсе AxelNAC перейдите в раздел Конфигурация → Настройки системы → База данных → Расширенные и увеличьте значение параметра Размер буферного пула InnoDB.

Шаг 6. Перезапустите службу packetfence-mariadb с помощью команды:

systemctl restart packetfence-mariadb

Шаг 7. Подождите 10 минут, затем повторно проверьте iostat и CPU.

uptime
12:01:58 up 235 days, 1:46, 1 user, load average: 0.15, 0.39, 0.52
iostat 5
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
cciss/c0d0 8.00 0.00 75.20 0 376
avg-cpu: %user %nice %sys %iowait %idle
0.60 0.00 2.99 13.37 83.03
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
cciss/c0d0 14.97 0.00 432.73 0 2168
avg-cpu: %user %nice %sys %iowait %idle
0.20 0.00 2.60 6.60 90.60
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
cciss/c0d0 4.80 0.00 48.00 0 240

Исключение ошибок «Host <hostname> is blocked»

В условиях беспроводной сети, как правило, происходит большое количество соединений с базой данных, которые выполняет модуль freeradius. При загрузке сервера эти попытки соединения могут прерываться по времени. Если соединение прерывается во время подключения, MariaDB расценивает это как ошибку соединения и после 10 таких попыток (по умолчанию) блокирует хост с сообщением:

Host 'host_name' is blocked because of many connection errors. Unblock with 'mysqladmin flush-hosts'

Блокировка приведет к остановке AxelNAC, поэтому ее следует избегать. Один из способов сделать это — увеличить количество максимальных соединений, чтобы периодически очищать хосты или разрешать большее количество ошибок при соединении. Подробное описание решения этой ошибки описано в этой статье.

Использование MariaDB-backup

При работе с крупной базой данных сценарий резервного копирования и обслуживания базы данных /usr/local/pf/addons/backup-and-maintenance.sh, использующий mysqldump, может привести к длительной блокировке базы данных и к зависанию службы.

Это можно исправить с помощью службы MariaDB-backup, которая может выполнить полное резервное копирование базы данных без блокировки таблиц.

Шаг 1. Предоставьте соответствующие права пользователю PF (или тому, который был настроен в файле pf.conf):

mysql -u root -p
MariaDB> GRANT PROCESS, RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO
'pf'@'localhost';
MariaDB> FLUSH PRIVILEGES;

Шаг 2. Запустите сценарий обслуживания /usr/local/pf/addons/backup-and-maintenance.sh и убедитесь, что в его выводе присутствует следующая строка:

innobackupex: completed OK!

Шаг 3. Если резервное копирование закончилось неудачно, проверьте журнал /usr/local/pf/logs/innobackup.log и обратитесь к документации по MariaDB-backup для устранения неполадок.

совет

Если нужно прекратить использование MariaDB-backup для резервного копирования MariaDB, просто удалите его, и сценарий базы данных вернется к mysqldump.