PHP / MySQL: могут ли 12 ядер ЦП создавать приложения быстрее, чем 6 ядер ЦП, хотя загрузка ЦП всегда ниже 40%?
наша проблема в том, что MySQL откладывает наше приложение после того, как мы сократили количество ядер ЦП, хотя загрузка ЦП всегда была и была ниже 40%. Мой вопрос: действительно ли сокращение ЦП привело к замедлению работы MySQL? Или я должен искать в другом месте?
Более подробная информация: Моя команда запускает мобильное приложение, в котором одновременно могут работать до нескольких тысяч пользователей. Они запускают до 100 запросов в секунду к бэкэнду. Мы используем PHP / MySQL и имели 12 процессорных ядер и 8 ГБ оперативной памяти. Инструмент phpMyAdmin показал, что загрузка ЦП составляет 15-25%, а использование ОЗУ — 1 ГБ.
Затем мы сократили количество ядер ЦП до 6. Максимальная загрузка ЦП возросла примерно до 40%. Однако, столкнувшись с более высокой нагрузкой (но не более высокой, чем у нас при работе с 12 ядрами), MySQL не может обработать все запросы сразу, и запросы выстраиваются в очередь, задерживая все наше приложение. Этого не произошло, когда у нас было 12 ядер.
Буду благодарен за любые советы или подсказки. Мы уже проводим полный обзор конфигурации сервера (переменной). Мы используем только InnoDB-таблицы.
Большое спасибо,
Fman
Решение
Мне кажется, что ваш MySQL, вероятно, достигает пределов ввода-вывода. Мы провели стресс-тестирование на нашем сервере БД, и что очень важно для понимания дросселирования БД, так это то, что при добавлении или изменении записей необходимо выполнять запись на диск (SELECT можно кэшировать). Поэтому, когда мы только читали наш веб-сайт, он выдерживал довольно большую нагрузку, но когда мы имитировали оформление заказа (было создано несколько записей), он очень быстро зависал.
Тогда у нас не было никаких вариантов. Твердотельные накопители были слишком дорогими, чтобы их можно было использовать по сравнению с магнитными (и наше количество дросселей было намного выше всего, что мы когда-либо действительно поражали). Лучшим, что мы могли бы сделать, был RAID 10. Но благодаря облакам вы можете легко (и дешево) иметь довольно мощный сервер БД, который будет намного лучше справляться с нагрузками ввода-вывода (особенно с быстрым падением цен на SSD). Вы заметите, что Amazon продает даже свои средние экземпляры на Предоставленная функция IOPS
Для любого производственного приложения, требующего высокой и стабильной производительности ввода-вывода, мы рекомендуем выделенное хранилище ввода-вывода (операций ввода-вывода в секунду). Предоставленное хранилище IOPS — это тип хранилища, который обеспечивает быструю, предсказуемую и стабильную производительность. Когда вы создаете экземпляр БД, вы указываете скорость IOPS и распределение дискового пространства. Amazon RDS предусматривает, что IOPS оценивает и хранит в течение всего времени существования экземпляра БД или до тех пор, пока вы его не измените. Предоставленное хранилище IOPS оптимизировано для интенсивных рабочих нагрузок ввода-вывода и оперативной обработки транзакций (OLTP), которые соответствуют требованиям производительности.
Это звучит очень похоже на то, что вы, вероятно, имеете простую настройку (и, возможно, даже разместите свою БД на том же сервере). AWS — не единственная игра в городе, но вы можете подумать о переходе на какое-то облако или, по крайней мере, перейти на что-то, что может удовлетворить более высокие требования ввода-вывода, которые вы предъявляете к своему серверу. Забудьте количество ядер. Если ваш жесткий диск задыхается, вы можете использовать 72 ядра и не иметь никакой разницы.
Еще один совет: проверить MySQL Tuner. Когда вы запускаете его, он проверяет статистику вашей базы данных (чем дольше он работает, тем лучше) и может порекомендовать множество полезных настроек, которые также могут повысить производительность.
Другие решения
Других решений пока нет …