Тот же запрос, одна и та же система, другое время выполнения

Запросы ниже всех выполняются мгновенно на нашем сервере разработки, где они могут занимать до 2 минут 20 секунд.Тот же запрос, одна и та же система, другое время выполнения

Время выполнения запроса, по-видимому, зависит от неоднозначности строки LIKE дома. Если они близки к стране, у которой мало совпадений, потребуется меньше времени, и если вы используете что-то вроде «ge» для германии, это займет больше времени. Но это не всегда так получается, временами его довольно неустойчивое.

Отправка данных, по-видимому, является виновником, но почему и что это значит. Также память на производстве выглядит довольно низкой (свободная память)?

Производство:
Intel Quad Xeon E3-1220 3.1GHz
4GB DDR3
2x 1TB SATA в RAID1
Скорость сети 100Mb
Ubuntu

Разработка
Intel Core i3- 2100, 2C/4T, 3.10GHz
500 ГБ SATA - нет RAID
4GB DDR3

Этот запрос НЕ является вопросом, о котором идет речь, но связан с тем, что он плохо связан с ним.

SELECT 
    f.form_question_has_answer_id 
FROM 
    form_question_has_answer f 
INNER JOIN 
    project_company_has_user p ON f.form_question_has_answer_user_id = p.project_company_has_user_user_id 
INNER JOIN 
    company c ON p.project_company_has_user_company_id = c.company_id 
INNER JOIN 
    project p2 ON p.project_company_has_user_project_id = p2.project_id 
INNER JOIN 
    user u ON p.project_company_has_user_user_id = u.user_id 
INNER JOIN 
    form f2 ON p.project_company_has_user_project_id = f2.form_project_id 
WHERE 
    (f2.form_template_name = 'custom' AND p.project_company_has_user_garbage_collection = 0 AND p.project_company_has_user_project_id = '29') AND (LCASE(c.company_country) LIKE '%ge%' OR LCASE(c.company_country) LIKE '%abcde%') AND f.form_question_has_answer_form_id = '174'

И план объяснить для приведенного выше запроса, работать как на разработчика и производства производят один и тот же план.

+----+-------------+-------+--------+----------------------------------------------------------------------------------------------------------------------------------------------+----------------------------------+---------+----------------------------------------------------+------+-------------+ 
| id | select_type | table | type | possible_keys                                | key        | key_len | ref            | rows | Extra  | 
+----+-------------+-------+--------+----------------------------------------------------------------------------------------------------------------------------------------------+----------------------------------+---------+----------------------------------------------------+------+-------------+ 
| 1 | SIMPLE  | p2 | const | PRIMARY                                  | PRIMARY       | 4  | const            | 1 | Using index | 
| 1 | SIMPLE  | f  | ref | form_question_has_answer_form_id,form_question_has_answer_user_id                   | form_question_has_answer_form_id | 4  | const            | 796 | Using where | 
| 1 | SIMPLE  | u  | eq_ref | PRIMARY                                  | PRIMARY       | 4  | new_klarents.f.form_question_has_answer_user_id | 1 | Using index | 
| 1 | SIMPLE  | p  | ref | project_company_has_user_unique_key,project_company_has_user_user_id,project_company_has_user_company_id,project_company_has_user_project_id | project_company_has_user_user_id | 4  | new_klarents.f.form_question_has_answer_user_id | 1 | Using where | 
| 1 | SIMPLE  | f2 | ref | form_project_id                                | form_project_id     | 4  | const            | 15 | Using where | 
| 1 | SIMPLE  | c  | eq_ref | PRIMARY                                  | PRIMARY       | 4  | new_klarents.p.project_company_has_user_company_id | 1 | Using where | 
+----+-------------+-------+--------+----------------------------------------------------------------------------------------------------------------------------------------------+----------------------------------+---------+----------------------------------------------------+------+-------------+

Этот запрос длится 2 минуты ~ 20 секунд.

Запрос, ФАКТИЧЕСКИ выполняется на сервере это одна:

SELECT 
    COUNT(*) AS num_results 
FROM (SELECT 
     f.form_question_has_answer_id 
    FROM 
     form_question_has_answer f 
    INNER JOIN 
     project_company_has_user p ON f.form_question_has_answer_user_id = p.project_company_has_user_user_id 
    INNER JOIN 
     company c ON p.project_company_has_user_company_id = c.company_id 
    INNER JOIN 
     project p2 ON p.project_company_has_user_project_id = p2.project_id 
    INNER JOIN 
     user u ON p.project_company_has_user_user_id = u.user_id 
    INNER JOIN 
     form f2 ON p.project_company_has_user_project_id = f2.form_project_id 
    WHERE 
     (f2.form_template_name = 'custom' AND p.project_company_has_user_garbage_collection = 0 AND p.project_company_has_user_project_id = '29') AND (LCASE(c.company_country) LIKE '%ge%' OR LCASE(c.company_country) LIKE '%abcde%') AND f.form_question_has_answer_form_id = '174' 
    GROUP BY 
     f.form_question_has_answer_id;) dctrn_count_query;

С объяснить планы (опять же на разработчика и производства):

+----+-------------+-------+--------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------------------------------+---------+----------------------------------------------------+------+------------------------------+ 
    | id | select_type | table | type | possible_keys                                           | key        | key_len | ref            | rows | Extra      | 
    +----+-------------+-------+--------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------------------------------+---------+----------------------------------------------------+------+------------------------------+ 
    | 1 | PRIMARY  | NULL | NULL | NULL                                              | NULL        | NULL | NULL            | NULL | Select tables optimized away | 
    | 2 | DERIVED  | p2 | const | PRIMARY                                             | PRIMARY       | 4  |             | 1 | Using index     | 
    | 2 | DERIVED  | f  | ref | form_question_has_answer_form_id,form_question_has_answer_user_id                              | form_question_has_answer_form_id | 4  |             | 797 | Using where     | 
    | 2 | DERIVED  | p  | ref | project_company_has_user_unique_key,project_company_has_user_user_id,project_company_has_user_company_id,project_company_has_user_project_id,project_company_has_user_garbage_collection | project_company_has_user_user_id | 4  | new_klarents.f.form_question_has_answer_user_id | 1 | Using where     | 
    | 2 | DERIVED  | f2 | ref | form_project_id                                           | form_project_id     | 4  |             | 15 | Using where     | 
    | 2 | DERIVED  | c  | eq_ref | PRIMARY                                             | PRIMARY       | 4  | new_klarents.p.project_company_has_user_company_id | 1 | Using where     | 
    | 2 | DERIVED  | u  | eq_ref | PRIMARY                                             | PRIMARY       | 4  | new_klarents.p.project_company_has_user_user_id | 1 | Using where; Using index  | 
    +----+-------------+-------+--------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------------------------------+---------+----------------------------------------------------+------+------------------------------+

На сервере информация у меня следующая.

При исполнении:

+-------------+ 
| num_results | 
+-------------+ 
|   3 | 
+-------------+ 
1 row in set (2 min 14.28 sec)

Показать профиль:

+--------------------------------+------------+ 
| Status       | Duration | 
+--------------------------------+------------+ 
| starting      | 0.000016 | 
| checking query cache for query | 0.000057 | 
| Opening tables     | 0.004388 | 
| System lock     | 0.000003 | 
| Table lock      | 0.000036 | 
| init       | 0.000030 | 
| optimizing      | 0.000016 | 
| statistics      | 0.000111 | 
| preparing      | 0.000022 | 
| executing      | 0.000004 | 
| Sorting result     | 0.000002 | 
| Sending data     | 136.213836 | 
| end       | 0.000007 | 
| query end      | 0.000002 | 
| freeing items     | 0.004273 | 
| storing result in query cache | 0.000010 | 
| logging slow query    | 0.000001 | 
| logging slow query    | 0.000002 | 
| cleaning up     | 0.000002 | 
+--------------------------------+------------+

На развитие результаты заключаются в следующем.

+-------------+ 
| num_results | 
+-------------+ 
|   3 | 
+-------------+ 
1 row in set (0.08 sec)

Снова профиль для этого запроса:

+--------------------------------+----------+ 
| Status       | Duration | 
+--------------------------------+----------+ 
| starting      | 0.000022 | 
| checking query cache for query | 0.000148 | 
| Opening tables     | 0.000025 | 
| System lock     | 0.000008 | 
| Table lock      | 0.000101 | 
| optimizing      | 0.000035 | 
| statistics      | 0.001019 | 
| preparing      | 0.000047 | 
| executing      | 0.000008 | 
| Sorting result     | 0.000005 | 
| Sending data     | 0.086565 | 
| init       | 0.000015 | 
| optimizing      | 0.000006 | 
| executing      | 0.000020 | 
| end       | 0.000004 | 
| query end      | 0.000004 | 
| freeing items     | 0.000028 | 
| storing result in query cache | 0.000005 | 
| removing tmp table    | 0.000008 | 
| closing tables     | 0.000008 | 
| logging slow query    | 0.000002 | 
| cleaning up     | 0.000005 | 
+--------------------------------+----------+

Если я удалить пользователя и/или проект innerjoins запрос сводится к 30-х годов.

Последний бит информации у меня есть:

Mysqlserver и Apache находятся на том же поле, есть только одна коробка для производства.

Выход продукции сверху: до & после.

top - 15:43:25 up 78 days, 12:11, 4 users, load average: 1.42, 0.99, 0.78 
Tasks: 162 total, 2 running, 160 sleeping, 0 stopped, 0 zombie 
Cpu(s): 0.1%us, 50.4%sy, 0.0%ni, 49.5%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st 
Mem: 4037868k total, 3772580k used, 265288k free, 243704k buffers 
Swap: 3905528k total, 265384k used, 3640144k free, 1207944k cached 

top - 15:44:31 up 78 days, 12:13, 4 users, load average: 1.94, 1.23, 0.87 
Tasks: 160 total, 2 running, 157 sleeping, 0 stopped, 1 zombie 
Cpu(s): 0.2%us, 50.6%sy, 0.0%ni, 49.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st 
Mem: 4037868k total, 3834300k used, 203568k free, 243736k buffers 
Swap: 3905528k total, 265384k used, 3640144k free, 1207804k cached

Но это не хорошее представление о нормальном состоянии производства, с тем здесь является захват его с сегодняшнего дня за пределами выполнения запросов.

top - 11:04:58 up 79 days, 7:33, 4 users, load average: 0.39, 0.58, 0.76 
Tasks: 156 total, 1 running, 155 sleeping, 0 stopped, 0 zombie 
Cpu(s): 3.3%us, 2.8%sy, 0.0%ni, 93.9%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st 
Mem: 4037868k total, 3676136k used, 361732k free, 271480k buffers 
Swap: 3905528k total, 268736k used, 3636792k free, 1063432k cached

Разработка: Это не меняется во время или после.

top - 15:47:07 up 110 days, 22:11, 7 users, load average: 0.17, 0.07, 0.06 
Tasks: 210 total, 2 running, 208 sleeping, 0 stopped, 0 zombie 
Cpu(s): 0.1%us, 0.2%sy, 0.0%ni, 99.7%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st 
Mem: 4111972k total, 1821100k used, 2290872k free, 238860k buffers 
Swap: 4183036k total, 66472k used, 4116564k free, 921072k cached

источник

2012-05-30 mr12086

Сколько данных в базе данных разработки по сравнению с производственной базой данных? –

Кроме того, является развитие местного производства и производства в сети? –

Базы данных являются точными совпадениями, для разработки используется ежедневная свалка из жизни. – mr12086

Если промежуток времени прерывистый, это либо загрузка сервера, либо другой конфликт ресурсов (в вашем случае, скорее всего, память). В вашей системе должно быть достаточно ОЗУ для хранения всех индексов в памяти сразу, в противном случае ему придется поменять память, если нужный индекс еще не загружен в ОЗУ.

Ваши ТОП результаты показывают, что имеется достаточное количество ОЗУ.

Используйте настройку innodb_buffer_pool_size для настройки размера пула буферов для InnoDB и key_buffer_size для MyISAM. Убедитесь, что вы установили его достаточно высоко, чтобы одновременно удерживать все индексы в ОЗУ, и чтобы ваша система имела достаточное количество оперативной памяти для этого.

источник

2012-05-30 15:59:26

Медленность - это каждый раз, когда я запускаю запрос, когда он не кэшируется. Если я удаляю внутренние соединения для пользователя и/или проекта, результат сводится к 30-секундному исполнению! Что это значит? – mr12086

@ mr12086, используйте [SQL_NO_CACHE] (http://dev.mysql.com/doc/refman/5.0/en/select.html), чтобы подтвердить, что он кэширует и заменяет память. –

Я выполняю запрос с параметром SQL_NO_CACHE, но что это должно показать мне? Это просто означает, что каждый раз, когда я запускаю запрос, он не кэшируется, поэтому занимает> 2 минуты каждый раз. Будет ли что-то еще, если это произойдет с заменой памяти? – mr12086

Отправка данных | 136.213836

Очевидно: D

Это должно быть какой-то вопрос инфраструктуры ... Сеть или что-то, попробуйте пинговать сервер с вашего SQL/плюс терминал, и вы будете иметь свой ответ

источник

2012-05-30 14:16:01 Sebas

Он хочет знать, почему. –

@aF Точно. И что делает загадочным то, что он просто возвращает единственное значение ('COUNT (*)'), так что это не проблема с пропускной способностью. –

ОБЪЯСНИТЬ -план обычно является лучшим местом для начала, когда у вас медленный запрос. Чтобы получить один, запустите

DESCRIBE SELECT 
    COUNT(*) AS num_results 
FROM (SELECT 
     f.form_question_has_answer_id 
    FROM 
     form_question_has_answer f 
    INNER JOIN 
     project_company_has_user p ON f.form_question_has_answer_user_id = p.project_company_has_user_user_id 
    INNER JOIN 
     company c ON p.project_company_has_user_company_id = c.company_id 
    INNER JOIN 
     project p2 ON p.project_company_has_user_project_id = p2.project_id 
    INNER JOIN 
     user u ON p.project_company_has_user_user_id = u.user_id 
    INNER JOIN 
     form f2 ON p.project_company_has_user_project_id = f2.form_project_id 
    WHERE 
     (f2.form_template_name = 'custom' AND p.project_company_has_user_garbage_collection = 0 AND p.project_company_has_user_project_id = '29') AND (LCASE(c.company_country) LIKE '%finland%' OR LCASE(c.company_country) LIKE '%finnland%') AND f.form_question_has_answer_form_id = '174' 
    GROUP BY 
     f.form_question_has_answer_id;) dctrn_count_query;

Это покажет вам таблицу с описанием шагов, необходимых для выполнения вашего запроса. Если вы видите большое значение в столбце «rows» и NULL в столбце «key», это означает, что ваш запрос должен проверять большое количество строк, чтобы определить, какие из них нужно вернуть.

В этом случае добавление индекса по адресу destination_id должно значительно ускорить ваш запрос, с некоторыми затратами на вставку и удаление скорости (так как индекс также необходимо будет обновить).

источник

2012-05-30 14:19:26

Оба запроса идентичны, работают на идентичной структуре базы данных и на одинаковом количестве данных, поэтому они должны быть одинаково хорошо (или плохо) оптимизированы. –

Тогда, как @Sebas заявил, проблема пропускной способности в производстве! –

План descibe/explain указан выше, это может быть не идеально, но я не думаю, что это что-то, что должно быть сделано :) – mr12086

Если это link верно, то число, позади 'отправки данных', не является необходимым для отправки данных, а для "Сортировка результата".

Это, в свою очередь, может намекать на проблему с памятью или процессором на производственном сервере. Возможно, вам захочется ознакомиться с соответствующей статистикой на машинах.

источник

2012-05-30 14:30:01

Выполнение запросов при разработке и производстве и сравнение планов запросов. Если они отличаются, попробуйте обновить статистику по таблицам, участвующим в запросе.

источник

2012-05-30 14:40:46

Планы идентичны, все о них одинаково в разное время их выполнения. – mr12086

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

Кроме того, нагрузка на производственный сервер очень высока?

источник

2012-05-30 14:41:35 Jaydee

Нагрузка сервера на производство минимальна, никогда не высока и определенно не в настоящее время. - Я добавил верхний вывод в OP. – mr12086

Глядя снова на профиль, «Открытие таблиц» также значительно медленнее на машине разработки. Я подозреваю, что проблема памяти какая-то. Существует значительная разница в используемой памяти. Машина разработки: «Mem: 4111972k total, 1821100k used,« Production »Mem: 4037868k всего, 3817944k использовано,« – Jaydee

Я не знаком с оптимизатором в mysql.

Эта проблема возникает в конце запроса. Одна из возможностей - это взгляд, происходящий в производственной системе. Например, возможно, существует некоторая блокировка метаданных, которая препятствует созданию новой таблицы.

Кроме того, среда, в которой выполняется запрос влияет на оптимизатор. По крайней мере, несколько потоков/процессоров будут влиять на план запроса.Mysql может генерировать различные оптимизации запросов на основе доступных ресурсов. Я знаю, что SQL Server будет создавать разные планы запросов на основе доступной памяти - используя хеш-таблицы, когда имеется достаточно памяти, но вложенные петлевые соединения, когда доступно меньше. Являются ли все обоймы памяти одинаковыми на обеих системах?

источник

2012-05-30 14:42:07

Я собираюсь прийти в чистоту, я понятия не имею о распределении памяти, обе коробки - это Linux, у которых есть 4 ГБ, щелчок «вершины» на обеих коробках и отправьте его в одно мгновение. – mr12086

Тот же запрос, одна и та же система, другое время выполнения

ответ

Смежные вопросы