Неправильно написанный сценарий вызывает значительное потребление ресурсов

Недавно администратор сервера отправил отчет о сайте Joomla, который вызывает слишком много потребления ресурсов. В докладе говорится:

  

ПРИЧИНА ПОТРЕБЛЕНИЯ ВЫСОКОГО РЕСУРСА:

     

Мы провели подробное исследование, и выяснилось, что Joomla выполняет медленные запросы к своей базе данных, что в конечном итоге вызывает зависание сервера. Сервер пытается выполнить ваши медленные запросы при помещении других процессов в очередь до освобождения некоторой памяти. Хотя они ждут, они складываются и вызывают дополнительные проблемы. Могут быть много причин для медленных запросов к базе данных, но следующие 3 являются наиболее распространенными:

     
  1. Большая база данных
  2.   
  3. Неправильно написанные сценарии
  4.   
  5. Большое количество внутренних ссылок, которые напрямую запрашивают базу данных.
  6.   

Вот некоторые из запросов к базе данных, которые медленны и потребляют много ресурсов сервера:

     
  1. Выполнено 1 ч. 8 мин. 56s назад для 87.512348 сек. по базе данных -> sporthis_tory   Дата: 2015-08-24 22:24:22 Query_time: 87.512348 Rows_examined: 5593: Rows_sent 247 Lock_time: 0.000197   SELECT a.id, CASE WHEN CHAR_LENGTH (a.alias) THEN CONCAT_WS (':', a.id, a.alias) ELSE a.id END как slug, CASE WHEN CHAR_LENGTH (cc.alias) THEN CONCAT_WS (':' , cc.id, cc.alias) ELSE cc.id END as catslug FROM g06j5_content AS a LEFT JOIN g06j5_categories AS cc ON cc.id = a.catid WHERE a.catid = 105 И a.state = 1 AND a.access = 1 AND (a.state = 1 ИЛИ a.state = -1) AND (publish_up = '0000-00-00 00:00:00' OR publish_up = '2015-08-25 03:22:36') ORDER BY a.created DESC;   -------------------------------------------------- ----------------------------- > ------------------- ----
  2.   
  3. Выполнено 57m 7s назад для 67.095903 sec для базы данных -> sporthis_tory   Дата: 2015-08-24 22:36:11 Query_time: 67.095903 Rows_examined: 5593: Rows_sent 247 Lock_time: 0.000252   SELECT a.id, CASE WHEN CHAR_LENGTH (a.alias) THEN CONCAT_WS (':', a.id, a.alias) ELSE a.id END как slug, CASE WHEN CHAR_LENGTH (cc.alias) THEN CONCAT_WS (':' , cc.id, cc.alias) ELSE cc.id END as catslug FROM g06j5_content AS a LEFT JOIN g06j5_categories AS cc ON cc.id = a.catid WHERE a.catid = 105 И a.state = 1 AND a.access = 1 AND (a.state = 1 ИЛИ a.state = -1) AND (publish_up = '0000-00-00 00:00:00' OR publish_up = '2015-08-25 03:35:01') ORDER BY a.created DESC;   -------------------------------------------------- ----------------------------- > ------------------- ----
  4.   
  5. Выполнено 1 ч. 8 мин. 56 сек. назад для 52.137859 сек. База данных -> sporthis_tory   Дата: 2015-08-24 22:24:22 Query_time: 52.137859 Rows_examined: 5593: Rows_sent 247 Lock_time: 0.000169   SELECT a.id, CASE WHEN CHAR_LENGTH (a.alias) THEN CONCAT_WS (':', a.id, a.alias) ELSE a.id END как slug, CASE WHEN CHAR_LENGTH (cc.alias) THEN CONCAT_WS (':' , cc.id, cc.alias) ELSE cc.id END as catslug FROM g06j5_content AS a LEFT JOIN g06j5_categories AS cc ON cc.id = a.catid WHERE a.catid = 105 И a.state = 1 AND a.access = 1 AND (a.state = 1 ИЛИ a.state = -1) AND (publish_up = '0000-00-00 00:00:00' OR publish_up = '2015-08-25 03:22:52') ORDER BY a.created DESC;   -------------------------------------------------- ----------------------------- > ------------------- ----
  6.   
  7. Выполнено 1h 3m 29s назад для 45.861259 sec. База данных -> sporthis_tory   Дата: 2015-08-24 22:29:49 Query_time: 45.861259 Rows_examined: 5593: Rows_sent 247 Lock_time: 0.000650   SELECT a.id, CASE WHEN CHAR_LENGTH (a.alias) THEN CONCAT_WS (':', a.id, a.alias) ELSE a.id END как slug, CASE WHEN CHAR_LENGTH (cc.alias) THEN CONCAT_WS (':' , cc.id, cc.alias) ELSE cc.id END as catslug FROM g06j5_content AS a LEFT JOIN g06j5_categories AS cc ON cc.id = a.catid WHERE a.catid = 105 И a.state = 1 AND a.access = 1 AND (a.state = 1 ИЛИ a.state = -1) AND (publish_up = '0000-00-00 00:00:00' OR publish_up = '2015-08-25 03:28:40') ORDER BY a.created DESC;   -------------------------------------------------- ----------------------------- > ------------------- ----
  8.   
  9. Выполнено 1h 20m 37s назад для 40.682781 sec для базы данных -> sporthis_tory   Дата: 2015-08-24 22:12:41 Query_time: 40.682781 Rows_examined: 1320: Rows_sent 440 Lock_time: 0.000176   SELECT a.id, CASE WHEN CHAR_LENGTH (a.alias) THEN CONCAT_WS (':', a.id, a.alias) ELSE a.id END как slug, CASE WHEN CHAR_LENGTH (cc.alias) THEN CONCAT_WS (':' , cc.id, cc.alias) ELSE cc.id END as catslug FROM g06j5_content AS a LEFT JOIN g06j5_categories AS cc ON cc.id = a.catid WHERE a.catid = 111 AND a.state = 1 AND a.access = 1 AND (a.state = 1 ИЛИ a.state = -1) AND (publish_up = '0000-00-00 00:00:00' OR publish_up = '2015-08-25 03:11:50') ORDER BY a.created DESC;
  10.   

sporthis_tory 175.1 MB

     

Из вышеприведенных запросов можно сделать вывод, что ваша проблема вызвана неправильными сценариями.

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

Обновление:

Благодарим вас за полезную информацию. Я хочу добавить, что сайт не работает из-за потребления ресурсов, поэтому я не могу войти в систему, чтобы перейти к панели администратора joomla, пока не исправлю это. Я выполнил объяснение, расширенное с запросом, и получил этот результат > >

  

ID: 1
  SELECT_TYPE: SIMPLE
  таблица: а
  Тип: index_merge
  possible_keys: idx_access, idx_state, idx_catid
  key: idx_catid, idx_state, idx_access
  Key_len: 4,1,4
  ref: NULL
  строк: 1275
  фильтруют: 75,06 -   Дополнительно: использование intersect (idx_catid, idx_state, idx_access); Использование где; Использование filesort

     

id: 1
  select_type: ПРОСТОЕ
  стол: cc
  Тип: const
  possible_keys: ПЕРВЫЙ
  по ключевому слову: PRIMARY
  Key_len: 4
  ссылка: Const
  строк: 1
  фильтруют: 100,00 -   Дополнительно:

У меня нет опыта по индексированию баз данных, и я хочу получить это право, мне нужно создать новый индекс со всеми тремя столбцами (idx_catid, idx_state, idx_access) или они уже проиндексированы? Также на дополнительной заметке я предполагаю, что этот запрос исходит от модуля joomla, есть ли способ, каким образом я могу обнаружить, какой модуль выполняет эти странные запросы? Обратите внимание, что я не создатель сайта, меня попросили решить эту проблему.

2 голоса | спросил Agapios Iwsifidis 25 PM00000040000003831 2015, 16:04:38

1 ответ


1

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

Сначала, как устранить эти проблемы. Поскольку они дают вам медленные запросы, вы должны начать, видя, почему они медленны! База данных сообщит вам об этом в определенной степени, поэтому войдите в свою БД (либо используя командную строку, либо что-то вроде PhpMyAdmin). Запустите один из медленных запросов со словом EXPLAIN в начале:

  

EXPLAIN SELECT a.id, CASE WHEN CHAR_LENGTH (a.alias) THEN CONCAT_WS (':', a.id, a.alias) ELSE a.id END как slug, CASE WHEN CHAR_LENGTH (cc.alias) THEN CONCAT_WS (':', cc.id, cc.alias) ELSE cc.id END как catslug FROM g06j5_content AS a LEFT JOIN g06j5_categories AS cc ON cc.id = a.catid WHERE a.catid = 105 AND a.state = 1 AND a.access = 1 AND (a.state = 1 ИЛИ a.state = -1) AND (publish_up = '0000-00-00 00:00:00' OR publish_up = '2015-08-25 03:22:36 ') ORDER BY a.created DESC;

Это даст вам таблицу данных, сообщающую вам, как ваша база данных будет получать эту информацию. Вещи, которые я ожидал увидеть в этом (без фактического запуска объяснения ...):

  • Соединение находится в id для #__categories, поэтому необходимо загрузить дополнительную таблицу с помощью клавиши
  • Он также должен указать вам, какой ключ (если он есть) используется для загрузки записей из таблицы #__content. Joomla по умолчанию поставляется с индексом catid, state и access, которые находятся в вашем предложении WHERE и поэтому могут быть использованы

Моя рекомендация по оптимизации обычно заключается в том, чтобы выяснить, какой индекс она пытается использовать, а затем добавить в таблицу лучший индекс для поддержки такого типа запросов. (И помните, что компромисс с индексами всегда увеличивает время чтения для более медленного времени записи, поэтому, если вы добавляете множество индексов, вы должны иметь возможность быстрее выбирать записи, но добавлять новые записи медленнее.)

При взгляде на все, что вы выбираете, вы хотите указать конкретный catid, state и access, поэтому добавление индекса, который использует все три из этих столбцов в одном, должен позволить DB выбирать правильные строки еще быстрее. Все еще будут какие-то процессы БД, поскольку они должны сортировать их по created, чтобы заказать их.

Чтобы на самом деле принять ваше решение, я рекомендую скопировать базу данных для вашего сайта на местном уровне, добавить разные индексы в таблицу g06j5_content и продолжить выполнение этого EXPLAIN, пока вы не получите запрос для запуска в основном из индексов.


Еще одно замечание, вы можете видеть в своих запросах, что вы выполняете как проверку на a.state = 1, так и (a.state = 1 OR a.state = -1). Это, очевидно, бесполезная проверка, поскольку состояние не может равняться 1 и -1 для одной и той же записи, что означает, что в этом случае (a.state = 1 OR a.state = -1) бесполезно.

Я не рекомендую отслеживать что-либо подобное и удалять его, поскольку в БД есть оптимизатор запросов, который удалит вторую проверку (поскольку она не добавляет значения).

Если вы хотите на самом деле изменить запрос, я бы хотел выяснить, почему вы выбираете два точных значения publish_up: (publish_up = '0000-00-00 00:00:00' OR publish_up = '2015-08-25 03:11:50') .

Нет индекса в publish_up раз, поэтому обычно это означает, что БД должна искать каждую запись, чтобы найти, является ли это правдой или нет. Я не уверен, что подкрепляющая логика заключается в выборе по определенному времени публикации, так как это будет редко быть правдой.

ответил David Fritsch 25 PM00000060000003331 2015, 18:15:33

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

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132