Производительность MySQL - PullRequest
       13

Производительность MySQL

3 голосов
/ 28 апреля 2010

У меня есть это приложение LAMP с около 900k строк в MySQL, и у меня есть некоторые проблемы с производительностью.

Справочная информация. Помимо стека LAMP, существует также Java-процесс (многопоточный), который выполняется в собственной JVM. Таким образом, вместе с LAMP & Java они составляют полное решение. Процесс Java отвечает за вставки / обновления, а также несколько вариантов выбора. Эти вставки / обновления обычно бывают групповыми / пакетными, где-то между 5-150 строками. Интерфейсный код PHP выполняет только SELECT.

Проблема: запросы PHP / SELECT становятся очень медленными, когда запущен процесс Java. Когда Java-процесс остановлен, SELECT работает нормально. Я имею в виду разницу в производительности огромна. Когда процесс java запущен, любое действие, выполняемое на внешнем интерфейсе php, приводит к 80% и более использованию ЦП для процесса mysqld.

Любая помощь будет оценена.

MySQL работает с параметрами и настройками по умолчанию.

Программный стек -

  • Apache - 2.2.x
  • MySQL -5.1.37-1ubuntu5
  • PHP - 5.2.10
  • Java - 1.6.0_15
  • ОС - Ubuntu 9.10 (кармический)

Ответы [ 2 ]

4 голосов
/ 29 апреля 2010

Какой движок вы используете для MySQL? Здесь следует отметить, что если вы используете MyISAM, то у вас будут проблемы с блокировкой из-за блокировки таблиц, которую использует движок.

От: Блокировка таблицы MySQL

Блокировка стола также невыгодна по следующему сценарию:

* A session issues a SELECT that takes a long time to run.
* Another session then issues an UPDATE on the same table. This session 
  waits until the SELECT is finished.
* Another session issues another SELECT statement on the same table.
  Because UPDATE has higher priority than SELECT, this SELECT waits for the UPDATE to finish, 
  after waiting for the first SELECT to finish.

Я не буду повторять их здесь, но на странице есть несколько советов по увеличению параллелизма в таблице в MySQL. Очевидно, что одним из вариантов было бы перейти на механизм, подобный InnoDB, который имеет более сложный механизм блокировки строк, который для таблиц с высокой степенью параллелизма может иметь огромное значение в производительности. Для получения дополнительной информации о InnoDB перейдите здесь . Прежде чем менять движок, возможно, стоит взглянуть на другие советы, такие как проверка правильности индексации таблицы и т. Д., Поскольку это повысит производительность выбора и обновления независимо от механизма хранения.

Редактирование на основе комментария пользователя:

Я бы сказал, что это одно из возможных решений, основанное на симптомах, которые вы описали, но оно не может быть тот, который доставит вас туда, где вы хотите быть. Это невозможно сказать без дополнительной информации. Вы можете выполнять полное сканирование таблицы из-за отсутствия индексов. Это может вызвать конфликт ввода-вывода на вашем диске, что еще больше усиливает блокировки таблиц, используемые MyISAM. Если это так, то корень причины - неправильное индексирование и исправление, которое будет вашим лучшим способом действий перед сменой хранилища двигателей.

Кроме того, убедитесь, что ваши таблицы нормализованы. Это может иметь серьезные последствия для производительности особенно на обновлениях. Нормализованные таблицы могут позволить вам обновить одну строку вместо сотен или тысячи в ненормализованной таблице. Это связано с не дублированными значениями. Это также может сэкономить огромное количество I / O on выбирает, поскольку БД может более эффективно кэшировать блоки данных. Не зная структуры Таблицы, с которыми вы работаете, или представленные вами индексы, трудно предоставить вам более подробный ответ.

Редактировать после попытки пользователя использовать InnoDB:

Вы упомянули, что ваш Java-процесс является многопоточным. Вы пытались запустить процесс с одним потоком? Мне интересно, может быть, вы отправляете одни и те же строки для обновления в несколько потоков и / или способ обновления между потоками вызывает проблемы с блокировкой.

Помимо этого, я бы проверил следующее:

  1. Проверяли ли вы свои планы объяснения, чтобы убедиться, что у вас есть разумные расходы и что запрос фактически использует ваши индексы?
  2. Ваши таблицы нормализованы? Точнее, обновляете ли вы 100 строк, когда можно было бы обновить одну запись, если таблицы были нормализованы?
  3. Возможно ли, что у вас заканчивается физическая память, когда запущен Java-процесс, и машина занята загрузкой и выгрузкой?
  4. Вы заполняете свой диск (один диск?) Большим количеством IOP, чем он может разумно обработать?
0 голосов
/ 29 апреля 2010

Нам нужно знать намного больше о системе, чтобы сказать, нормально ли это или как решить проблему.

около 900 тыс. Строк в MySQL

Я бы сказал, что это делает его очень маленьким - поэтому, если он работает плохо, вы где-то идете серьезно не так.

Включите журнал запросов, чтобы точно увидеть, какие запросы выполняются, расставьте приоритеты на основе произведения частоты и продолжительности. Посмотрите на планы объяснения, создайте несколько индексов. Подумайте о разделении базы данных на несколько дисков.

НТН

C.

...