Производительность Azure Wordpress MySQL
У меня есть 3 базы данных mariadb galera, 2 машины nginx/php этих размеров. БД — E8ds_v5, nginx/php-fpm — D4ds_V5 У меня очень плохая производительность от mariadb. Эти машины находятся в одной виртуальной сети, но в разных подсетях для базы данных и сети. Два сервера nginx/php-fpm обмениваются веб-файлами через общий доступ к файлам Azure и премиум-файлу nfs, который, похоже, работает нормально.
Я попытался обновить хранилище БД до P40 без каких-либо изменений в производительности. В настоящее время тестируется обновленный размер экземпляра (тестируется только один сервер) до E20ds_v5, Storage at Premium SSDv2 (30 000 операций ввода-вывода в секунду, 500 МБ/с).
Я провожу тесты WordPress и синхронизирую запросы к базе данных для базовой установки WordPress без каких-либо изменений в оценке, независимо от того, что делается. Базовая установка WordPress в данный момент направлена непосредственно на обновленную машину. Мой следующий шаг — попробовать использовать MySQL Flex, но было бы здорово, если бы я смог заставить работать этот самостоятельный mariadb. Независимо от того, сколько настроек было сделано, все остается по-прежнему, медленно.
Я думаю, что самая большая проблема заключается в том, что я получаю ужасную производительность, если MySQL не работает локально там, где обрабатывается PHP.
Запрошена информация о базе данных Galera
Вот результаты тестов с помощью Инструмента Wordpress Hosting Benchmark с различными настройками.
Тестирование nginx/php-fpm/mariadb на той же виртуальной машине (Standard_D1_v2) - NODATA
Бенчмарк nginx/php-fpm/mariadb на той же виртуальной машине (Standard_D1_v2) - С ДАННЫМИ
Запрос дополнительной информации по БД, пожалуйста. ОС, версия? Размер ОЗУ, # ядер на хост-сервере Azure MySQL? Публикуйте ТЕКСТОВЫЕ данные на justpaste.it и делитесь ссылками. В корне вашего входа в систему SSH отображаются текстовые результаты: A) SELECT COUNT(*) FROM information_schema.tables; Б) ПОКАЗАТЬ ГЛОБАЛЬНЫЙ СТАТУС; минимум через 24 часа РАБОТЫ C) ПОКАЗАТЬ ГЛОБАЛЬНЫЕ ПЕРЕМЕННЫЕ; D) ПОКАЗАТЬ ПОЛНЫЙ СПИСОК ПРОЦЕССОВ; Д) СТАТУС; не ПОКАЗАТЬ СТАТУС, а просто СТАТУС; G) ПОКАЗАТЬ СТАТУС INNODB ДВИГАТЕЛЯ; для анализа настройки рабочей нагрузки сервера и предоставления предложений. Добро пожаловать в СО.
спасибо, добавил dbinfo и информацию/изображения тестов
Где физически расположены три узла Galera?
Эти изображения могут быть полезны для сравнения различных конфигураций для данного теста, но являются ли они репрезентативными для вашего приложения?
Все Лазурное, Восток США. Пять проблемных виртуальных машин находятся в двух AV-наборах: один для БД, другой для WEB. Целью изображений было показать лучшие результаты для БД при использовании небольшой виртуальной машины с запущенным на ней MySQL по сравнению с плохими оценками, если MySQL работает за пределами локального хоста.
Спасибо за опубликованную информацию о БД. Запрос дополнительной информации по БД, пожалуйста. ОС, версия? Размер ОЗУ, количество ядер, любой SSD или NVME для хранения данных на хост-сервере Azure MySQL? Анализ рабочей нагрузки в процессе.
Ubuntu 22.04 MariaDB 10.6, 8 процессоров, 64 ГБ ОЗУ (Azure E8ds_v5), твердотельный накопитель премиум-класса, максимальная скорость ввода-вывода 2300 операций ввода-вывода в секунду.
@naw_ Поскольку вы знаете, что SSD-накопитель Premium рассчитан на максимальную производительность 2300 операций ввода-вывода в секунду, рассмотрите возможность изменения innodb_io_capacity на 2300 с 7500, которые есть в вашей конфигурации на данный момент.
Анализ рабочей нагрузки завершен, предложения для рассмотрения см. в ответе от 25 марта 2024 г., около 11:19.
Ответы 2
Скорость в секунду = число запросов в секунду
Рекомендации, которые следует учитывать при выборе портала, настроек и параметров вашего сервера Azure.
innodb_buffer_pool_size=24G # from 48G until more than 10G is used
thread_pool_size=6 # from 16 you only have 8 cpu's
read_rnd_buffer_size=16384 # from 4M to reduce innodb_data_read RPS of 114,229
read_buffer_size=524288 # from 3M to reduce innodb_data_read RPS of 114,229
innodb_lru_scan_depth=100 # from 1024 to reduce 90% CPU cycles used for function.
Есть еще много возможностей улучшить производительность. Пожалуйста, просмотрите мой профиль.
Наблюдение, В innodb_ Secondary_index_triggered_cluster_reads было зарегистрировано 1 878 540 сообщений за 16 часов. Обычно это вызвано таблицами без первичного ключа. Для запроса на поиск таблиц такого типа укажите адрес электронной почты.
Я ценю ваш ответ, это привело меня к ответу. На самом деле дело в том, что NFS премиум-класса Azure Files в целом работает очень медленно. Возможно, из-за множества маленьких файлов в WordPress. Однако это показало мне, что в БД необходимо выполнить настройку. Значительное количество неправильных конфигураций было связано с альтернативными скоростями дисков и размерами виртуальных машин, которые мы пробовали.
Мы здесь, чтобы помочь. Когда ты готов.
Как вы оцениваете производительность после применения Предложений от 25 марта 2024 г. около 11:19? Лучше хуже?
примерно то же самое, я думаю, как только мы разберемся с проблемой хранения, мы сможем сосредоточиться на проблемах с БД
Проблема оказалась в медленной системе Azure Files NFS. Несмотря на то, что это был файловый ресурс Premium(Hot) NFS 4.1, он работал слишком медленно.
Мы построили собственный HA NFS-сервер и больше не имеем проблем с БД.
Если вы хотите, чтобы новая сборка работала еще быстрее, свяжитесь с нами.
Посмотрите, поможет ли этот плагин: wordpress.org/plugins/index-wp-mysql-for-speed