Можно ли сломать относительную загрузку MySQL по “источнику” запроса?
Можно ли сделать диагностику на массиве? возможно, массив не восстановил правильно по некоторым причинам. Сбой этого, это походит на личинку, возможно, нуждается в реконфигурировании, но не видя Вашу фактическую установку его трудное для знания, что попробовать.
Я предложил бы использовать MySQL Proxy. С MySQL Proxy можно прервать и зарегистрировать каждый запрос, входящий сервер.
Более простой подход работал бы mysqlbinlog проанализировать двоичные файлы журнала, сгенерированные MySQL (см. man mysqlbinlog).
Так или иначе, если бы Вы уже не сделали этого, это была бы хорошая идея работать mysqltuner видеть, существуют ли какие-либо очевидные проблемы или узкие места (как, например, необычное количество запросов, выполняющих СОЕДИНЕНИЯ без индексов).
Вы попытались войти в mysql сервис и выпустить ШОУ ПОЛНЫЙ PROCESSLIST или использовать mytop для наблюдения, какие запросы работают?
SHOW FULL PROCESSLIST предоставляет список всех запросов и определяет задачу для MySQL, в настоящее время делает. Это должно быть выполнено как пользователь или с 'ПРОЦЕССОМ' или с 'СУПЕР' полномочиями в базе данных. mysqladmin имеет processlist аргумент также.
mytop очень хорош для показа, что сервер делает на непрерывной основе. Думайте о нем как о чем-то как вершина для MySQL.
Оба из них скажут Вам, что выполняют команды, куда они происходят из и сколько времени MySQL пытался обслужить их до сих пор.
После того как Вы вооружены той информацией, можно пойти о решении, что сделать. Если система является записью, связал Вас, возможно, должен разделить Ваши данные. Если Вы читаетесь связанные, существуют вещи, которые могут помочь. Делительно-поворотные столы правильно могут дать значительное повышение производительности чтения во многих случаях. Если у Вас есть много идентичных запросов, добавляющих, что кэш может помочь. Добавление ведомых устройств чтения может также улучшить производительность. Кэширование и добавление ведомых устройств увеличат производительность, но добавят некоторую дополнительную сложность к Вашей сети и приложению.
Да Вы можете, но представляющий, не используя основанного на клиенте профилировщика требует, чтобы Вы передали запросы через что-то, что может поймать их - В этом случае, это будет MySql-прокси. Существуют инструкции относительно их веб-сайта о том, как настроить его, чтобы поймать и представить запросы, и затем можно работать, объясняет и другие операции против тех, которые, кажется, проводят долгое время.
Другой метод это не так сложно, но может работать, должен установить Ваш тайм-аут медленного запроса на очень низкую стоимость и затем удостовериться, что Вы поворачиваетесь, медленный запрос входят в систему. Тем путем Вы будете видеть что-либо, что занимает больше времени, чем несколько секунд. Это не поможет Вам, если разработчики (или их ORM) будут делать набор основных запросов и затем будут суммировать данные в приложении, конечно.
ПОКАЖИТЕ ПОЛНЫЙ PROCESSLIST;
Это показывает Вам процессы и время выполнения. Для дифференциации источника можно использовать различные логины для каждой 'области' ИЛИ предварительно ожидать область во всех запросах. например, это - допустимый запрос:
/* php */ВЫБИРАЮТ * ИЗ объектов;
как:
/* Java */ВЫБИРАЕТ * ИЗ объектов;
и т.д.
Но Вы все еще не видите системную нагрузку, вызванную запросами. Может быть полезным так или иначе, и Вы могли взломать свои контрольные инструменты для построения графика данных для поиска корреляций с производительностью.
Мы отмечаем запросы с комментариями, как mibus предложенный выше. Мы затем регулярно пишем ПОЛНЫЙ вывод PROCESSLIST в файлы. Когда у нас есть проблемы производительности, мы импортируем эти файлы в базу данных и munge данные для наблюдения долгих запросов. Для нас, по крайней мере, они вызывают большую часть загрузки.
Я был бы осторожен с рабочим MySQL Proxy в производственной системе. Я нашел, что это иногда запирается. Дополнительно у Вас есть дальнейшая часть инфраструктуры, которую необходимо контролировать.
У Вас есть изучение использования mysql профилирование?
http://dev.mysql.com/tech-resources/articles/using-new-query-profiler.html
mysql>set profiling=1;
<run your queries with profiling enabled>
mysql>show profiles;
Вывод этого будет таблицей с QueryID, Продолжительностью Запроса и Строкой запроса. Подобный этому:
mysql> show profiles;
+----------+------------+-----------------------------------------------+
| Query_ID | Duration | Query |
+----------+------------+-----------------------------------------------+
| 0 | 0.00007300 | set profiling=1 |
| 1 | 0.00044700 | select count(*) from client where broker_id=2 |
+----------+------------+-----------------------------------------------+
Отсюда, можно повредить тот запрос далее вниз с
mysql>show profile for query <QueryID>;
Это даст Вам разбивку того, сколько времени запрос провел на каждом этапе выполнения. Можно далее копаться в специфических особенностях того, сколько процессорного времени проведено на запрос также:
mysql> show profile cpu for query 4;
+----------------------+------------+------------+------------+
| Status | Duration | CPU_user | CPU_system |
+----------------------+------------+------------+------------+
| (initialization) | 0.00002900 | 0.00000000 | 0.00000000 |
| checking permissions | 0.00000800 | 0.00000000 | 0.00000000 |
| init | 0.00004000 | 0.00000000 | 0.00000000 |
| Opening table | 0.00009400 | 0.00100000 | 0.00000000 |
| System lock | 0.00000500 | 0.00000000 | 0.00000000 |
| Table lock | 0.00000700 | 0.00000000 | 0.00000000 |
| setup | 0.00004200 | 0.00000000 | 0.00000000 |
| creating table | 0.00195800 | 0.00000000 | 0.00100000 |
| After create | 0.00010900 | 0.00000000 | 0.00000000 |
| copy to tmp table | 0.52264500 | 0.55591600 | 0.04199300 |
| rename result table | 0.11289400 | 0.00199900 | 0.00000000 |
| end | 0.00004600 | 0.00000000 | 0.00000000 |
| query end | 0.00000700 | 0.00000000 | 0.00000000 |
| freeing items | 0.00001300 | 0.00000000 | 0.00000000 |
+----------------------+------------+------------+------------+
Я предлагаю читать информационную страницу для обнаружения точно, какую информацию Вы хотели бы, поскольку инструмент является довольно подробным, но это должно помочь Вам в нахождении Ваших узких мест в mysql демоне.
-
1Я должен добавить, что способ пойти от Вашего оскорбления запрашивает к обнаружению, кто запросил, чтобы это использовало general_log. Где это может быть стычкой для нахождения преступника, она также покажет Вам, где Вы проводите все свое время. Я думал бы, совершенствовав Ваш процессор, голодный запрос будет решением для конца. – sclarson 27 October 2009 в 21:01
Первый шаг не должен иметь всего Вашего использования процессов тот же пользователь. Особенно, если все они проникают через 'localhost'. Даже для запросов, прибывающих из того же инструмента (как в php), имейте, те в кроне используют отдельного пользователя от тех пробегающих апача.
После того как это сделано, можно использовать mysqlbinlog для парсинга медленных журналов (он имеет некоторые большие поля для упорядочивания запрашивать/нормализования запросы), или даже используйте что-то более усовершенствованное как профилировщик для нахождения более медленных запросов