Перейти до вмісту
Пошук в
  • Детальніше...
Шукати результати, які ...
Шукати результати в ...

Recommended Posts

Добрый день!
Идет большая нагрзука на сервер http://prntscr.com/l8kzl5
Предполгаю что это из-за длинных запросов.
Логи прилагю
Цели:
1.Понять нагрузка из-за длинных запросов
2.Почему стали происходить длинные запросы (ранее не было)
3.Что нужно сделать что бы вылечить текущую проблему и избежать далее нагрузок.

mysql-slow_(4).zip

Надіслати
Поділитися на інших сайтах


1 час назад, YulanaKiev сказал:

Привет, открой консоль разработчика в браузере загрузи страницу и повремени загрузки элементов все увидишь.

 

 

А причем здесь это к медленным запросам?

то что там order by LCACE(p.product_id)

я промолчу.

Надіслати
Поділитися на інших сайтах

весь лог не перелопатил, но в нем встречаются в осномном два тяжелых запроса.

Один типовой из стандартного метода опенкарта (getProducts из catalog\model\catalog\product.php):

Spoiler

SELECT
  p.product_id,
  (SELECT
      AVG(rating) AS total
    FROM oc_review r1
    WHERE r1.product_id = p.product_id
    AND r1.status = '1'
    GROUP BY r1.product_id) AS rating,
  (SELECT
      price
    FROM oc_product_discount pd2
    WHERE pd2.product_id = p.product_id
    AND pd2.customer_group_id = '1'
    AND pd2.quantity = '1'
    AND ((pd2.date_start = '0000-00-00'
    OR pd2.date_start < NOW())
    AND (pd2.date_end = '0000-00-00'
    OR pd2.date_end > NOW()))
    ORDER BY pd2.priority ASC, pd2.price ASC LIMIT 1) AS discount,
  (SELECT
      price
    FROM oc_product_special ps
    WHERE ps.product_id = p.product_id
    AND ps.customer_group_id = '1'
    AND ((ps.date_start = '0000-00-00'
    OR ps.date_start < NOW())
    AND (ps.date_end = '0000-00-00'
    OR ps.date_end > NOW()))
    ORDER BY ps.priority ASC, ps.price ASC LIMIT 1) AS special
FROM oc_category_path cp
  LEFT JOIN oc_product_to_category p2c
    ON (cp.category_id = p2c.category_id)
  LEFT JOIN oc_product p
    ON (p2c.product_id = p.product_id)
  LEFT JOIN oc_product_description pd
    ON (p.product_id = pd.product_id)
  LEFT JOIN oc_product_to_store p2s
    ON (p.product_id = p2s.product_id)
WHERE pd.language_id = '1'
AND p.status = '1'
AND p.date_available <= NOW()
AND p2s.store_id = '0'
AND cp.path_id = '2247'
AND LCASE(pd.name) LIKE '%Смеситель%'
AND LCASE(pd.name) LIKE '%для%'
GROUP BY p.product_id
ORDER BY LCASE(p.product_id) DESC, LCASE(pd.name) DESC LIMIT 0, 4;

но время выполнения просто невменяемое - местами более 15 сек о_О. Это при каждом открытии карточки товара такое.

 

а еще есть какой-то фильтр, который генерит безумные запросы со временем выполнения до 20сек, типа

Spoiler

SELECT
  COUNT(DISTINCT p.product_id) AS total,
  fpa.attribute_id,
  fpa.attribute_group_id,
  fpa.attribute_value_mod
FROM oc_oct_filter_product_attribute fpa
  INNER JOIN oc_product p USING (product_id)
WHERE fpa.product_id IN (84235, 84232, .. over9000 записей)
GROUP BY fpa.attribute_value_mod;

 

Налицо отсутствие оптимизации БД. Судя по всему, у Вас достаточно много товаров, а Mysql, поди, работает на дефолтовых конфигах

 

19 hours ago, vasuanin said:

1.Понять нагрузка из-за длинных запросов
2.Почему стали происходить длинные запросы (ранее не было)
3.Что нужно сделать что бы вылечить текущую проблему и избежать далее нагрузок.

1. Их всего несколько. Но запросы "типовые".

2. Их медленное выполнение может быть связано с целым рядом причин: отсутствие индексов, сильная фрагментация таблиц, резкое увеличение объема данных (импорт нескольких тысяч товаров или подобное). Точно сказать сложно без анамнеза.

3. Возможно, стоит поискать специалиста, который сначала займется настройкой сервера mysql. А затем, по результатам, решить - стоит ли оптимизировать сами запросы.

 

Могу взяться посмотреть\исправить. Мне интересно - скучаю иногда по "старой" работе (за плечами несколько лет корпоративной работы в должности админа баз данных). Пишите в ЛС, если что.

Змінено користувачем 100napb
Надіслати
Поділитися на інших сайтах

29 минут назад, 100napb сказал:

весь лог не перелопатил, но в нем встречаются в осномном два тяжелых запроса.

Один типовой из стандартного метода опенкарта (getProducts из catalog\model\catalog\product.php):

  Показать контент


SELECT
  p.product_id,
  (SELECT
      AVG(rating) AS total
    FROM oc_review r1
    WHERE r1.product_id = p.product_id
    AND r1.status = '1'
    GROUP BY r1.product_id) AS rating,
  (SELECT
      price
    FROM oc_product_discount pd2
    WHERE pd2.product_id = p.product_id
    AND pd2.customer_group_id = '1'
    AND pd2.quantity = '1'
    AND ((pd2.date_start = '0000-00-00'
    OR pd2.date_start < NOW())
    AND (pd2.date_end = '0000-00-00'
    OR pd2.date_end > NOW()))
    ORDER BY pd2.priority ASC, pd2.price ASC LIMIT 1) AS discount,
  (SELECT
      price
    FROM oc_product_special ps
    WHERE ps.product_id = p.product_id
    AND ps.customer_group_id = '1'
    AND ((ps.date_start = '0000-00-00'
    OR ps.date_start < NOW())
    AND (ps.date_end = '0000-00-00'
    OR ps.date_end > NOW()))
    ORDER BY ps.priority ASC, ps.price ASC LIMIT 1) AS special
FROM oc_category_path cp
  LEFT JOIN oc_product_to_category p2c
    ON (cp.category_id = p2c.category_id)
  LEFT JOIN oc_product p
    ON (p2c.product_id = p.product_id)
  LEFT JOIN oc_product_description pd
    ON (p.product_id = pd.product_id)
  LEFT JOIN oc_product_to_store p2s
    ON (p.product_id = p2s.product_id)
WHERE pd.language_id = '1'
AND p.status = '1'
AND p.date_available <= NOW()
AND p2s.store_id = '0'
AND cp.path_id = '2247'
AND LCASE(pd.name) LIKE '%Смеситель%'
AND LCASE(pd.name) LIKE '%для%'
GROUP BY p.product_id
ORDER BY LCASE(p.product_id) DESC, LCASE(pd.name) DESC LIMIT 0, 4;

но время выполнения просто невменяемое - местами более 15 сек о_О. Это при каждом открытии карточки товара такое.

 

 

Это не запрос, это просто треш какой то
Like '%....%' делает перебор по всей базе не используя индексы
Никакая "оптимизация" настроек MySQL не поможет с этим запросом
 

Надіслати
Поділитися на інших сайтах

39 minutes ago, markimax said:

Это не запрос, это просто треш какой то
Like '%....%' делает перебор по всей базе не используя индексы
Никакая "оптимизация" настроек MySQL не поможет с этим запросом
 

 

 ¯\_(ツ)_/¯


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

Змінено користувачем 100napb
Надіслати
Поділитися на інших сайтах

Створіть аккаунт або увійдіть для коментування

Ви повинні бути користувачем, щоб залишити коментар

Створити обліковий запис

Зареєструйтеся для отримання облікового запису. Це просто!

Зареєструвати аккаунт

Вхід

Уже зареєстровані? Увійдіть тут.

Вхід зараз
  • Зараз на сторінці   0 користувачів

    • Ні користувачів, які переглядиють цю сторінку
×
×
  • Створити...

Important Information

На нашому сайті використовуються файли cookie і відбувається обробка деяких персональних даних користувачів, щоб поліпшити користувальницький інтерфейс. Щоб дізнатися для чого і які персональні дані ми обробляємо перейдіть за посиланням . Якщо Ви натиснете «Я даю згоду», це означає, що Ви розумієте і приймаєте всі умови, зазначені в цьому Повідомленні про конфіденційність.