Вопросы Теги

Настройки Adjusting MySQL для обработки большой загрузки пользователей

Попробуйте tracert от обоих направлений. Они следуют за тем же маршрутом? Возможно, ответ с Вашего сервера идет на другой маршрут, который заблокирован.

1
задан 17 November 2010 в 02:29
4 ответа

Проблемы я предвижу..

1.) Mysql использует большую память для сотен/тысяч соединений дизайном..

В основном необходимо настроить confiuguration, чтобы помочь минимизировать использование памяти
Я не думаю, что это - проблема памяти
С базой данных 200 МБ и 32 ГБ установил Вас, не должен поражать Вашу максимальную память
Вы только имеете 250 пользователей и истратили ЦП

2.) Mysql дизайном, дает одно соединение/поток с ядром (это может быть совместно использовано),

Это, очевидно, может быть совместно использовано со многими потоками, но 1 наклон потока нарушает ядро.
Проблемой, которую Вы видите, являются слишком много "МЕДЛЕННЫХ/ТЯЖЕЛЫХ" запросов, посредством чего максимизация каждого ядра..
Поэтому Вы наклоняетесь, берут больше пользователей, как ЦП в его пределе..
- Начните представлять свои запросы
- Индексируйте правильно для чтений
- В случае необходимости используйте ведущее устройство записи и ведомое устройство чтения

Некоторые вопросы

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

4
ответ дан 3 December 2019 в 16:16

Это является довольно основным, но "mysql производительность, настраивающая сценарий краткой информации" (http://www.day32.com/MySQL/), обеспечивает некоторые хорошие предложения для начала работы.

В настоящее время это обрабатывает рекомендации для следующего:

  • Журнал медленного запроса
  • Соединения Max
  • Рабочие потоки
  • Ключевой буфер
  • Кэш запроса
  • Буфер вида
  • Соединения
  • Временные таблицы
  • Таблица (открытый и определение) кэш
  • Блокировка таблицы
  • Сканирования таблицы (read_buffer)
  • Состояние Innodb
3
ответ дан 3 December 2019 в 16:16

У меня только есть несколько точек, о которых необходимо думать.

32 ГБ RAM на в большой степени используемом сервере базы данных не являются "монстром", но она зависит от того, как Ваша база данных используется. Если у Вас есть огромное количество запросов - И данные (это требуют), не может все вписаться в RAM, у Вас будет серьезная проблема с дисковой системой, кующей ввод-вывод на хранении данных. Это не кажется на необходимость в большем количестве RAM поскольку Вы истратили ЦП.

1 600%-е использование ЦП равняется 16 логическим (8 физических) ядра на истратившем X7550. Необходимо отметить, что гиперпоточность на серверах баз данных высоко обсуждена, поскольку она обычно дает Вам крошечный бит большей производительности записи и крошечный бит меньше производительности чтения. С другой стороны, отключение его не решит Вашу проблему.

Это звучит мне как Ваша база данных, и/или Ваше приложение не разработано очень хорошо с точки зрения оптимизации и время обработки. 250 пользователей, буквально уничтожающих ядра на 8x2,4 ГГц, не являются чем-то, что я назвал бы обычным, и это не что-то, что mysql настройки сервера могут решить для Вас.

Я голосовал для перемещения этого вопроса Переполнению стека.

4
ответ дан 3 December 2019 в 16:16
  • 1
    за подробное отвечает. В этом случае я не полагаю, что это - сам сценарий и как это обрабатывает базу данных. Очевидно, у меня есть большие несколько запросы тут и там, но ничто, что помещает сервер в это положение. То, что я думаю, - то, что некоторая установка должна быть неправильной где-нибудь? Как Вы говорите, 250 пользователей нечетны для порождения этого большого количества проблемы о сервере. Вы могли любезно дать мне некоторую подсказку на том, что я мог искать для решения этой проблемы? Я знаю, что это - неопределенный вопрос, но я потерян... –  Peter Foster 17 November 2010 в 02:52
  • 2
    Думайте об этом - если mysqld использует 1 600%-ю мощность ЦП - какую волшебную установку Вы ищете? Что-то, чтобы заставить его использовать меньше мощности ЦП (так, чтобы запросы, выполненные медленнее)? У Вас, очевидно, есть что-то в Вашем приложении, которое заставляет mysqld обработать что-то. –  pauska 17 November 2010 в 02:56
  • 3
    Да достаточно ярмарка. Могли Вы совет меня того, как отладить проблему? –  Peter Foster 17 November 2010 в 03:02
  • 4
    Представьте свой код, xdebug.org используют mysql журналы медленного запроса и видят, какие querie (s) вызывают проблемы. Использование объясняет на всех Ваших общих запросах и удостоверяется, что все использует индексы, когда они должны. –  Zoredache 17 November 2010 в 03:04
  • 5
    Почему Переполнение стека.. Администраторы имеет дело с этим материалом каждый день.. Это быть их задание, чтобы отлаживать проблемы и обеспечивать решения управления и разработчиков.. Я голосует за него, чтобы остающийся.. –  Arenstar 17 November 2010 в 04:07

Я могу дать некоторые общие предложения, поскольку более определенная оптимизация является трудной/невозможной для "слепого" диагноза:

  • Значение по умолчанию my.cnf использует очень низкопроизводительные настройки (по крайней мере все по умолчанию, которые я видел). Существует разнообразие примера my.cnf там, чтобы дать Вам общее представление о том, что запустить с (поиск "mysql my.cnf оптимизация"). Знайте, что точные настройки, которые необходимо скорректировать, зависят от приложения так настройки, которые работают хорошо на кого-то еще, не мог бы работать также на Вас.
  • Высказывание "250 пользователей" не является достаточной информацией. Действительно ли чтение-запись приложения тяжело? Сколько запросов в секунду на пользователя?
  • База данных правильно разработана для производительности в памяти? Каждая таблица имеет индексную установку для часто используемых запросов? Действительно ли запросы просты, сложны, или суперсложны? Знайте о "глюках" в запросах, которые могут представить заказы величин проблем производительности. Вы фильтруете записи на использовании стороны базы данных, "ГДЕ" или Вы фильтруете на стороне сервера путем запроса и игнорирования нескольких записей на запрос?
  • Для базы данных 200 МБ с корректными my.cnf настройками весь рабочий набор базы данных должен легко вписаться в RAM, особенно с сервером с 32 ГБ памяти.
  • Если Ваше приложение прочитано нагруженное сложными запросами, затем смотрят на кэширующуюся стратегию уменьшить нагрузку на сервер MySQL.
  • Как сравнение: у Меня есть сервер MySQL, 1/5-й способность (ЦП/RAM) Вашего сервера, что средние числа 100 запросов/секунда для сайта MediaWiki и всегда на 90-95% неактивны. Хотя я не знаю детали Вашего приложения/установки, я думаю несколькими тонкими настройками my.cnf и некоторым приложением и базой данных, profiling/optimization, можно увеличить производительность порядком величины или два.
  • Если Вы серьезно относитесь к разработке MySQL, изучают получение книги MySQL High Performance. Это - замечательный обзор установки и использования MySQL для неопытных пользователей. MySQL High Performance Blog является также большим сайтом к частому.
0
ответ дан 3 December 2019 в 16:16

Теги

Похожие вопросы