Я разработал игру на php, которая явно зависит от запросов mysql. Я запускаю его на сервере-монстре: Intel Xeon 7550 с 32 ГБ ОЗУ (Redhat x86_64 ES 5.0) с установленной cPanel. Я выпустил игру на Facebook, и только 250 пользователей могли использовать ее, прежде чем процессор перестал работать.
Я был наверху и следил за загрузкой процессора. MySQL в какой-то момент использовал до 1600%! Все остальное было около 3%. Очевидно, мне нужно настроить параметры mysql, чтобы выпустить его в большем масштабе.
Извините, если этот вопрос расплывчатый. Мои знания о настройке параметров сервера mysql очень ограничены. Какие настройки мне нужно настроить? И что мне их настроить? Полагаю, это воспоминание - одно из них? Я предполагаю, что пользовательская база будет насчитывать 10 000 сеансов, работающих одновременно. С моими текущими настройками у меня может быть только 250. Любые советы опытных администраторов серверов будут очень признательны.
У меня есть только пара моментов, о которых вам следует подумать.
32 ГБ ОЗУ на активно используемом сервере баз данных - это не «монстр», но это зависит от того, как используется ваша база данных. Если у вас есть миллиард запросов - И данные (которые запрашиваются) не могут полностью поместиться в ОЗУ, у вас возникнет серьезная проблема с дисковой системой, забивающей операции ввода-вывода в хранилище данных. Не похоже, что вам нужно больше ОЗУ, так как вы максимально используете процессор.
Использование ЦП 1600% соответствует 16 логическим (8 физическим) ядрам на максимальной мощности X7550. Следует отметить, что гиперпоточность на серверах баз данных очень обсуждается, поскольку обычно дает вам немного больше производительности записи и немного меньше производительности чтения. С другой стороны, отключение не решит вашей проблемы.
Мне кажется, ваша база данных и / или ваше приложение не очень хорошо спроектированы с точки зрения оптимизации и времени обработки. 250 пользователей, буквально убивающих ядра 8x2,4 ГГц, - это не то, что я бы назвал обычным, и это не то, что настройки сервера mysql могут решить за вас.
Я проголосовал за перенос этого вопроса в Stack Overflow.
Проблемы, которые я предвижу ...
1.) Mysql по своей задумке использует много памяти для сотен / тысяч соединений.
В основном вам нужно настроить конфигурацию, чтобы минимизировать использование памяти.
Я не думаю, что это проблема с памятью
С базой данных 200 МБ и установленной 32 ГБ вы не должны использовать максимальную память
У вас всего 250 пользователей, и ваш ЦП полностью загружен
2.) Mysql по дизайну дает одно соединение / поток для ядра (это может быть общим)
Это, очевидно, может использоваться многими потоками, но один поток не может нарушить ядро.
Проблема, которую вы видите, - это слишком много запросов типа "МЕДЛЕННЫЙ / ТЯЖЕЛЫЙ", в результате чего каждое ядро максимально увеличивается
Поэтому вы не можете принимать больше пользователей, так как ЦП на пределе.
- Начните профилировать свои запросы
- Правильное индексирование для чтения
- При необходимости используйте ведущее устройство записи и ведомое устройство чтения.
Некоторые вопросы
What is your ratio READS / WRITES???
Have you tried Slow_query logging ( set it to 1 second )?
Have you used "explain" on queries to see if indexing is working?
Have you considered a job queue for writes?
Are you using the mysql cache effectively for reads?
Реально ваша проблема - плохие запросы / вставки ..
Если вы можете решить эту проблему, мы поможем вам с настройкой, чтобы минимизировать использование памяти.
Конфигурация в основном не предлагает много помощи с использованием ЦП, это зависит от вашего кода!
Надеюсь, это ясно: D
Это довольно простой вариант, но "сценарий для начинающих по настройке производительности mysql" (http://www.day32.com/MySQL/) дает несколько хороших советов для начала.
В настоящее время он обрабатывает рекомендации по следующему:
- Журнал медленных запросов
- Максимальное количество подключений
- Рабочие потоки
- Ключевой буфер
- Кэш запросов
- Сортировка буфера
- Присоединяется
- Таблицы температуры
- Кэш таблицы (открытый и определяющий)
- Блокировка стола
- Сканирование таблиц (read_buffer)
- Статус Innodb
Я могу дать несколько общих предложений, так как более конкретные оптимизации трудны / невозможны для "слепой" диагностики: