MySQL продовжує висіти (запити застрягли при надсиланні даних)

У мене така ситуація:

Приблизно 5 разів на тиждень (не пов’язане з якоюсь конкретною ситуацією, наприклад, кеш-пам'ять, швидкість руху) деякі запити затримуються при надсиланні даних ( show processlist):

>     SELECT `main_table`.`entity_id`, `main_table`.`level`, `main_table`.`path`, `main_table`.`position`,
> `main_table`.`is_active`, `main_table`.`is_anchor`,
> `main_table`.`name`, `url_rewrite`.`request_path` FROM
> `catalog_category_flat_store_30` AS `main_table`
>      LEFT JOIN `core_url_rewrite` AS `url_rewrite` ON url_rewrite.category_id=main_table.entity_id AND
> url_rewrite.is_system=1 AND url_rewrite.product_id IS NULL AND
> url_rewrite.store_id='30' AND url_rewrite.id_path LIKE 'category/%'
> WHERE (path LIKE '1/2/%') AND (main_table.store_id = '30') AND
> (is_active = '1') AND (include_in_menu = '1') ORDER BY name ASC

другий:

> SELECT `main_table`.`entity_id`, main_table.`name`, main_table.`path`,
> `main_table`.`is_active`, `main_table`.`is_anchor`,
> `main_table`.`manually`, `url_rewrite`.`request_path` FROM
> `catalog_category_flat_store_10` AS `main_table`  LEFT JOIN
> `core_url_rewrite` AS `url_rewrite` ON
> url_rewrite.category_id=main_table.entity_id AND
> url_rewrite.is_system=1 AND url_rewrite.product_id IS NULL AND
> url_rewrite.store_id='10' AND url_rewrite.id_path LIKE 'category/%'
> WHERE (main_table.is_active = '1') AND (main_table.include_in_menu =
> '1') AND (main_table.path like '1/2/1528/1569/%') AND (`level` <= 4)
> ORDER BY `main_table`.`position` ASC

Ці запити пов'язані з генерацією навігаційного меню. Вони бігають без жодних проблем і дуже швидко весь час.

Декілька разів на місяць деякі інші запити застрягають щодо завантаження даних або очікування блокування таблиці:

INSERT INTO `catalogsearch_result` SELECT 316598 AS `query_id`, `s`.`product_id`, MATCH (s.data_index) AGAINST ('STRING HERE' IN BOOLEAN MODE) AS `relevance` FROM `catalogsearch_fulltext` AS `s`
INNER JOIN `catalog_product_entity` AS `e` ON e.entity_id = s.product_id WHERE (s.store_id = 38) AND (MATCH (s.data_index) AGAINST ('STRING HERE' IN BOOLEAN MODE)) ON DUPLICATE KEY UPDATE `relevance` = VALUES(`relevance`)

(пошук пов'язаний)

Додаткова інформація:

• core_url_rewrite - 3M записи (30 веб-сайтів, 100k продуктів)
• catalog_category_flat_store_ * - 2000 записів (увімкнено використання плоских категорій)

Це працює в налаштуваннях, використовуючи vmware на величезному апаратному забезпеченні (майстер mysql має 8 ядер і 64 Гб оперативної пам’яті, SSD-диски на сховищі SAN), mysql був оптимізований і постійно контролюється. У минулому були проблеми, що стосуються вводу-виводу (деякі дослідження із зв'язком між серверами та сховищем SAN).

Ми не змогли точно визначити проблему, оскільки використання на голому металі (без віртуалізації, однакова конфігурація) цього не відбувається ніколи, в умовах високого стресу (запущена облога + сценарії тестування навантаження, без кешу).

Хтось ще має подібні проблеми?

ОНОВЛЕННЯ:

пошук reindexВсі був переміщений до тимчасової таблиці (тому він не блокує основну таблицю, використовувану виробництвом, а потім перейменовує таблицю tmp). Отже, процес перевстановлення не заважає відвідувачам шукати веб-сайт. https://github.com/magendooro/magento-fulltext-reindex kudos to carco

Це виглядає як основна помилка / регресія, яку ми побачили в 1.7, де кеш блоку та колекції не працювали ефективно для навігаційного меню ( catalog/navigation/top.phtml).

Ви можете перевірити, видаливши його, або просто тимчасово зафіксуйте висновок у файл із файлом ob_startта подайте його зі статичного файлу / мемаша.

Крім того, обладнання, яке ви використовуєте, не здається величезним і виглядає за вказаними розмірами магазину. Там, мабуть, і вузьке вузьке вузьке місце - сховище SAN + перевантажена мережа = низька продуктивність.

-

Як неочищене рішення, ви можете налаштувати клас блоків для навігації (дамп get_class($this)) top.phtmlдля його ідентифікації.

Це дозволить кешувати загальний сайт, без кешування на рівні категорії, до якого викликалася нова версія. Також варто вилучити is_activeклас з дерева-рендерінга, якщо це зробити, щоб уникнути вибраних випадкових елементів меню (а замість цього застосувати альтернативу JS).

public function getCacheTags()
{
  return parent::getCacheTags();
}
public function getCacheLifetime()
{
  return null;
}
public function getCacheKey()
{
  return parent::getCacheKey();
}
public function getCacheKeyInfo()
{
  $shortCacheId = array(
    'CATALOG_NAVIGATION',
    Mage::app()->getStore()->getId(),
    Mage::getDesign()->getPackageName(),
    Mage::getDesign()->getTheme('template'),
    Mage::getSingleton('customer/session')->getCustomerGroupId(),
    'template' => $this->getTemplate(),
    'name' => $this->getNameInLayout(),
  );
  $cacheId = $shortCacheId;
  $shortCacheId = array_values($shortCacheId);
  $shortCacheId = implode('|', $shortCacheId);
  $shortCacheId = md5($shortCacheId);
  $cacheId['short_cache_id'] = $shortCacheId;
  return $cacheId;
}

Замініть функцію на

app / code / core / Mage / Каталог / Helper / Категорія / URL-адреса / Rewrite.php:

/**
* Join url rewrite to select
*
* @param Varien_Db_Select $select
* @param int $storeId
* @return Mage_Catalog_Helper_Category_Url_Rewrite
*/
public function joinTableToSelect(Varien_Db_Select $select, $storeId)
{
$select->joinLeft(
array('url_rewrite' => $this->_resource->getTableName('core/url_rewrite')),
'url_rewrite.category_id=main_table.entity_id'
);
$select->where('url_rewrite.is_system = ?', '1');
$select->where($this->_connection->quoteInto('url_rewrite.store_id = ?', (int)$storeId));
$select->where($this->_connection->prepareSqlCondition('url_rewrite.id_path', array('like' => 'category/%')));
$select->where('request_path = url_rewrite.request_path');

return $this;
}

У нашому випадку воно дійшло до цього повільного запиту:

SELECT `main_table`.`entity_id`
      , `url_rewrite`.`request_path`
FROM `catalog_product_entity` AS `main_table` 
INNER JOIN `catalog_product_website` AS `w`
   ON main_table.entity_id = w.product_id 
LEFT JOIN `core_url_rewrite` AS `url_rewrite`
   ON url_rewrite.product_id = main_table.entity_id
   AND url_rewrite.is_system = 1
   AND url_rewrite.category_id IS NULL
   AND url_rewrite.store_id = 1
   AND url_rewrite.id_path LIKE 'product/%'
WHERE (w.website_id='1')

з програми / коду / core / Mage / Sitemap / Модель / Ресурс / Каталог / Product.php .

Він зависає через оператор category_id IS NULL . MySQL чомусь не використовував індекс.

Видалення категорії_id IS NULL та встановлення id_path REGEXP '^ product / [0-9] + $' усунуло проблему.

Скопіюйте додаток / код / ​​core / Mage / Каталог / Helper / Продукт / URL / Rewrite.php у додаток / код / ​​локальний / Mage / Каталог / Помічник / Продукт / URL / Rewrite.php та додайте цю функцію:

public function joinTableToSelectPatch(Varien_Db_Select $select, $storeId)
{ 
$select->joinLeft(
    array('url_rewrite' => $this->_resource->getTableName('core/url_rewrite')),
    'url_rewrite.product_id = main_table.entity_id AND url_rewrite.is_system = 1 AND ' .
        $this->_connection->quoteInto('url_rewrite.store_id = ? AND ',
            (int)$storeId) .
        $this->_connection->prepareSqlCondition('url_rewrite.id_path', array('regexp' => '^product/[0-9]+$')),
    array('request_path' => 'url_rewrite.request_path'));
return $this;
}

Потім скопіюйте додаток / код / ​​core / Mage / Sitemap / Model / Resource / Catalog / Product.php у додаток / код / ​​локальний / Mage / Sitemap / Model / Resource / Catalog / Product.php та змініть рядок 72 на:

$urlRewrite->joinTableToSelectPatch($this->_select, $storeId);

Спочатку взято з https://www.goivvy.com/blog/solved-magento-stuck-generating-google-sitemap-large-website