У меня проблема с использованием ЦП на веб-сайте, использующем WordPress, Apache и MySQL. В течение дня время от времени загрузка процессора MySQL и Apache доходит до 2400% (всего у меня 24 ядра), сервер зависает, средняя нагрузка доходит до 24.
В последнее время трафика было немного больше, чем обычно, но это не должно быть постоянным, верно? Обновлял ядро, базу, библиотеки, много раз перезагружал. И все равно замерзает. Я посмотрел список процессов БД, но ничего экстраординарного там нет. В базе есть довольно большие объемы данных. Буквально пару недель назад все работало нормально, а сейчас нет. Таким образом, это не должны быть неоптимизированные запросы.
Какие могут быть причины такого поведения?
Обновлять:
результат A) SHOW GLOBAL STATUS LIKE 'com_%r%_table';
+-----------------------+-------+
| Имя_переменной | Значение |
+-----------------------+-------+
| Com_alter_table | 5 |
| Com_create_table | 34 |
| Com_drop_table | 0 |
| Com_rename_table | 0 |
| Com_show_create_table | 0 |
+-----------------------+-------+
5 рядов в сете (3,04 сек)
B) ПОКАЗАТЬ ГЛОБАЛЬНЫЙ СТАТУС, КАК 'uptime%';
+---------------------------+---------+
| Имя_переменной | Значение |
+---------------------------+---------+
| Время работы | 455524 |
| Uptime_since_flush_status | 455524 |
+---------------------------+---------+
2 ряда в сете (0,01 сек)
C) ПОКАЗАТЬ ГЛОБАЛЬНЫЙ СТАТУС, КАК '%dirty%';
+-----------------+--------+
| Имя_переменной | Значение |
+-----------------+--------+
| Innodb_buffer_pool_pages_dirty | 0 |
| Innodb_buffer_pool_bytes_dirty | 0 |
+-----------------+--------+
2 ряда в наборе (0,00 сек)
p.s. У меня до сих пор проблемы с сервером.
Мне нужно было изменить набор символов в одной из баз данных, и это заняло чуть больше суток, всего 400 000 строк. Раньше это занимало некоторое время, но не так много. Мне было интересно, может ли быть так, что после DDOS-атаки могут быть какие-то изменения в базе данных, чтобы она работала хуже?
Обновление 2:
результаты mysqltuner:
[--] Пропущена проверка версии для скрипта MySQLTuner
[OK] Выполнен вход с использованием учетных данных из учетной записи обслуживания Debian.
[OK] В настоящее время работает поддерживаемая версия MySQL 8.0.26-0ubuntu0.20.04.2
[OK] Работа на 64-битной архитектуре
-------- Файл журнала Рекомендации --------------------------------------- ---------------------------
[OK] Файл журнала /var/log/mysql/error.log существует
[--] Лог-файл: /var/log/mysql/error.log(0B)
[--] Лог-файл /var/log/mysql/error.log пуст. Предполагая ротацию логов. Используйте --server-log={file} для явного файла
-------- Статистика механизма хранения --------------------------------------- --------------------------
[--] Статус: +ARCHIVE +BLACKHOLE +CSV -FEDERATED +InnoDB +MEMORY +MRG_MYISAM +MyISAM +PERFORMANCE_SCHEMA
[--] Данные в таблицах InnoDB: 262.4G (Таблицы: 179)
[OK] Всего фрагментированных таблиц: 0
-------- Показатели производительности анализа --------------------------------------- -----------------------
[--] innodb_stats_on_metadata: ВЫКЛ.
[OK] Статистические данные не обновляются при запросе INFORMATION_SCHEMA.
-------- Рекомендации по безопасности ---------------------------------------- --------------------------
[--] Пропущено из-за неподдерживаемой функции для MySQL 8
-------- Рекомендации по безопасности CVE --------------------------------------- -----------------------
[OK] ДЛЯ ВАШЕЙ ВЕРСИИ НЕ НАЙДЕНО CVE БЕЗОПАСНОСТИ
-------- Показатели эффективности ---------------------------------------- -------------------------------
[--] Up for: 5d 11h 4m 6s (15M q [31,945 qps], 191K соединений, TX: 80G, RX: 2G)
[--] Чтение/запись: 99%/1%
[--] Включено бинарное логирование (GTID MODE: OFF)
[--] Физическая память: 31,4 ГБ
[--] Максимальный объем памяти MySQL: 9,8 ГБ
[--] Другая память процесса: 0B
[--] Всего буферов: 176.0M глобальных + 65.1M на поток (151 макс. поток)
[--] P_S Максимальное использование памяти: 72Б
[--] Galera GCache Максимальное использование памяти: 0B
[OK] Максимально достигнутое использование памяти: 9,8 ГБ (31,14% установленной оперативной памяти)
[OK] Максимально возможное использование памяти: 9,8 ГБ (31,14% установленной оперативной памяти)
[OK] Общее возможное использование памяти другим процессом совместимо с доступной памятью
[OK] Медленные запросы: 0% (0/15M)
[!!] Максимальное использование соединения: 100% (151/151)
[OK] Прерванные соединения: 0,09% (174/191712)
[!!] разрешение имен активно: для каждого нового соединения выполняется обратное разрешение имен, что может снизить производительность
[--] Кэш запросов удален в MySQL 8
[OK] Сортировки, требующие временных таблиц: 0% (0 временных сортировок / 5 миллионов сортировок)
[OK] Нет объединений без индексов
[OK] Временные таблицы, созданные на диске: 0% (0 на диске / всего 2M)
[OK] Показатель попаданий в кэш потоков: 92 % (15 000 созданных / 191 000 подключений)
[OK] Частота попаданий в табличный кэш: 99% (21 млн обращений / 21 млн запросов)
[OK] table_definition_cache(2000) превышает количество таблиц(506)
[OK] Используемый лимит открытых файлов: 0% (6/10K)
[OK] Блокировки таблицы получены немедленно: 100% (9 немедленных / 9 блокировок)
[OK] Доступ к кэш-памяти Binlog: 99,57% (25538 памяти / 25647 всего)
-------- Схема производительности ---------------------------------------- --------------------------------
[--] Память, используемая P_S: 72B
[--] Схема Sys установлена.
-------- Показатели ThreadPool ---------------------------------------- --------------------------------
[--] Статистика ThreadPool отключена.
-------- Показатели MyISAM ---------------------------------------- ------------------------------------
[--] Метрики MyISAM отключены в последних версиях MySQL.
-------- Метрики InnoDB ---------------------------------------- ------------------------------------
[--] InnoDB включен.
[--] Параллелизм потоков InnoDB: 0
[OK] Файл InnoDB для каждой таблицы активирован
[!!] Буферный пул InnoDB/размер данных: 128.0M/262.4G
[!!] Отношение размера файла журнала InnoDB к размеру буферного пула InnoDB (75%): 48,0M * 2/128,0M должно быть равно 25%
[OK] Экземпляры буферного пула InnoDB: 1
[--] Количество фрагментов буферного пула InnoDB: 1 на 1 экземпляр(ы) буферного пула
[OK] Innodb_buffer_pool_size приведен в соответствие с Innodb_buffer_pool_chunk_size и Innodb_buffer_pool_instances
[OK] Эффективность буфера чтения InnoDB: 98,29% (925392031 совпадений/всего 941450541)
[!!] Эффективность InnoDB Write Log: 309,39% (25100125 обращений/всего 8112662)
[!!] Ожидания журнала InnoDB: 0,00% (65 ожиданий / 33212787 записей)
-------- Метрики Арии ---------------------------------------- --------------------------------------
[--] Механизм хранения Aria недоступен.
-------- Показатели TokuDB ---------------------------------------- ------------------------------------
[--] TokuDB отключен.
-------- Метрики XtraDB ---------------------------------------- ------------------------------------
[--] XtraDB отключен.
-------- Галера Метрика ---------------------------------------- ------------------------------------
[--] Галера отключена.
-------- Показатели репликации ---------------------------------------- -------------------------------
[--] Galera Синхронная репликация: НЕТ
[--] Для этого сервера нет подчиненных(ых) репликации.
[--] Формат бинлога: ROW
[--] Поддержка XA включена: ВКЛ.
[--] Мастер полусинхронной репликации: не активирован
[--] Полусинхронная репликация Slave: не активирована
[--] Это автономный сервер
-------- Рекомендации ----------------------------------------- ----------------------------------
Общие рекомендации:
Уменьшите или устраните постоянные подключения, чтобы уменьшить использование подключений.
Настройте свои учетные записи только с IP-адресом или подсетями, затем обновите свою конфигурацию с помощью skip-name-resolve=1.
Перед изменением innodb_log_file_size и/или innodb_log_files_in_group прочтите это: *ссылка*
Переменные для настройки:
max_connections (> 151)
ожидание_время ожидания (< 28800)
интерактивный_тайм-аут (< 28800)
innodb_buffer_pool_size (>= 262,4 ГБ), если это возможно.
innodb_log_file_size должен быть (= 16M), если это возможно, поэтому общий размер файлов журнала InnoDB равен 25% размера буферного пула.
innodb_log_buffer_size (>= 16M)
Обновление 3:
Сегодня мой сервер снова завис. Процесс, который перегрузил ЦП, был apache2. Мне удалось остановить службу. И вдруг все стало работать гладко. Я попытался сделать резервную копию базы данных с большим количеством строк, и это сработало просто отлично. Но через какое-то время опять все замерло: загрузка ЦП некоторыми процессами была на уровне 2400%, средняя загрузка превысила 24. Так что мое предположение, что не апач нагружает ЦП, и не MySQL. Некоторые процессы, такие как htop или gzip, которые я использую для резервного копирования, также время от времени сильно загружают ЦП. Что это может быть тогда? Может ли это быть результатом DDOS-атаки, и если да, то как это исправить?
