phpBB ВЫБИРАЕТ last long time на новом сервере

ProgramBox

phpBB ВЫБИРАЕТ last long time на новом сервере

Post author:admin
Запись опубликована:24 апреля, 2023
Post category:Вопросы по программированию

#mysql #phpbb3

Вопрос:

Я настраиваю новый сервер и хочу перенести туда существующую установку phpBB. Все прошло нормально, за исключением того, что один SELECT находится в МЕДЛЕННОМ журнале и постоянно потребляет процессор. Я не специалист по БД, поэтому я потерян.

Старый сервер — Win2008 R2, MySQL 5.7.24, php 5.6.39, один четырехъядерный процессор i7, 24 ГБ оперативной памяти

Новый сервер — Win2016, MySQL 8.0.15, php 7.1.5, два процессора Xeon, 96 ГБ оперативной памяти

Я попытался открыть каждую таблицу и проверить наличие ошибок, выполнил mysql_upgrade с положительным результатом. Проблемный ВЫБОР:

 SELECT ug.user_id, a.forum_id, r.auth_setting, r.auth_option_id, ao.auth_option
            FROM phpbb_acl_groups a, phpbb_user_group ug, phpbb_groups g, phpbb_acl_roles_data r, phpbb_acl_options ao
            WHERE a.auth_role_id = r.role_id AND r.auth_option_id = ao.auth_option_id 
                AND a.group_id = ug.group_id
                AND g.group_id = ug.group_id
                AND ug.user_pending = 0
                AND NOT (ug.group_leader = 1 AND g.group_skip_auth = 1)


                AND ao.auth_option = 'm_';

На старом сервере выбор выполняется немедленно. На новом сервере это длится 25-30 секунд. Смотрите картинки — посмотрите на «проверенные строки». Но все таблицы выглядят нормально…

Новый сервер

Старый сервер

Старый сервер my.ini выглядит следующим образом:

 max_connections=151
table_open_cache=2000
tmp_table_size=922M
myisam_max_sort_file_size=100G
myisam_sort_buffer_size=3G
key_buffer_size=8M
read_buffer_size=64K
read_rnd_buffer_size=256K
innodb_flush_log_at_trx_commit=1
innodb_log_buffer_size=1M
innodb_buffer_pool_size=1024M
innodb_log_file_size=128M
innodb_thread_concurrency=17
innodb_autoextend_increment=64
innodb_buffer_pool_instances=8
innodb_concurrency_tickets=5000
innodb_old_blocks_time=1000
innodb_open_files=300
innodb_stats_on_metadata=0
innodb_file_per_table=1
innodb_checksum_algorithm=0
back_log=80
flush_time=0
join_buffer_size=256K
max_allowed_packet=4M
max_connect_errors=100
open_files_limit=4161
sort_buffer_size=256K
table_definition_cache=1400
binlog_row_event_max_size=8K
sync_master_info=10000
sync_relay_log=10000
sync_relay_log_info=10000

Новый сервер my.ini выглядит следующим образом:

 max_connections=151
table_open_cache=2000
tmp_table_size=5G
thread_cache_size=10
myisam_max_sort_file_size=100G
myisam_sort_buffer_size=10G
key_buffer_size=8M
read_buffer_size=64K
read_rnd_buffer_size=256K
innodb_flush_log_at_trx_commit=1
innodb_log_buffer_size=1M
innodb_buffer_pool_size=2048M
innodb_log_file_size=128M
innodb_thread_concurrency=24
innodb_autoextend_increment=64
innodb_buffer_pool_instances=8
innodb_concurrency_tickets=5000
innodb_old_blocks_time=1000
innodb_open_files=300
innodb_stats_on_metadata=0
innodb_file_per_table=1
innodb_checksum_algorithm=0
back_log=80
flush_time=0
join_buffer_size=256K
max_allowed_packet=4M
max_connect_errors=100
open_files_limit=4161
sort_buffer_size=256K
table_definition_cache=1400
binlog_row_event_max_size=8K
sync_master_info=10000
sync_relay_log=10000
sync_relay_log_info=10000

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

2. Я добавил свои конфигурации.ini в исходное сообщение как для старого, так и для нового сервера.

3. Пожалуйста, опубликуйте текстовые результаты отображения ГЛОБАЛЬНОГО СТАТУСА, НАПРИМЕР ‘% thread%’; и ПОКАЖИТЕ ГЛОБАЛЬНЫЕ ПЕРЕМЕННЫЕ, ТАКИЕ КАК ‘%thread%’; для более подробного просмотра вашего покрытия «thread» для вашей рабочей нагрузки.

4. @cz-mawa Если вы хотите сократить время ответа на запрос, пожалуйста, разместите сообщение со своего нового сервера — ПОКАЗАТЬ ГЛОБАЛЬНЫЙ СТАТУС; и ПОКАЗАТЬ ГЛОБАЛЬНЫЕ ПЕРЕМЕННЫЕ; для анализа настройки рабочей нагрузки сервера.

Ответ №1:

Итак, я:

сравнил данные каждой таблицы, столбцы, строки, индексы между старой и новой базой данных. Я не нашел ни единой разницы.
установил mysql 8.0.15 на другой компьютер и попробовал его там — на всякий случай, если на новом сервере что-то не так.

Безуспешно.

Итак, в качестве последней попытки я скачал текущую версию mysql 5.7.25 и угадайте, что — это работает.

Возможно ли, что это какая-то ошибка в ветке MySQL 8.x? Я не вижу другого объяснения…

1. Очевидно, вы обнаружили ошибку в версии 8.0.15. Я повторяю из предыдущего комментария, всякий раз, когда вы ПЕРЕХОДИТЕ к выпуску с МЕНЕЕ ЧЕМ 90 днями GA, вы указываете на свою готовность находить / сообщать об ошибках, которые были пропущены. Рад, что вы работаете сейчас. Пожалуйста, просмотрите мой профиль, Сетевой профиль для получения контактной информации.

Ответ №2:

Этот URL https://dev.mysql.com/doc/relnotes/mysql/8.0/en / указывает, что дата выпуска GA — 2019-02-01 для 8.0.15. Каждый раз, когда вы ПЕРЕХОДИТЕ к выпуску с МЕНЕЕ ЧЕМ 90 днями GA, вы выражаете свою готовность находить ошибки, которые были пропущены, или сообщать о них. Вы приняли мудрое решение вернуться к версии 5.7 с некоторой практической историей успеха в этой области. Возможно, вы захотите установить 180 дней ПОСЛЕ общей доступности, чтобы предотвратить обнаружение ошибок, которые просто еще не были исправлены, или сообщение об ошибках.