MySQL sigue colgando (consultas bloqueadas al enviar datos)

Tengo la siguiente situación:

Aproximadamente 5 veces a la semana (no relacionado con ninguna situación específica, como el borrado de caché, el pico de tráfico), algunas consultas están bloqueadas al enviar datos ( 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

segundo:

> 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

Estas consultas están relacionadas con la generación del menú de navegación. Se ejecutan sin problemas y muy rápido todo el tiempo.

Pocas veces al mes, algunas otras consultas se atascan al enviar datos o al esperar el bloqueo de la tabla:

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`)

(búsqueda relacionada)

Información adicional:

• core_url_rewrite - 3M registros (30 sitios web, 100k productos)
• catalog_category_flat_store_ * - 2000 registros (el uso de categorías planas está habilitado)

Esto se ejecuta en una configuración que usa vmware en un hardware enorme (mysql master tiene 8 núcleos asignados y 64 Gb de RAM, discos SSD en un almacenamiento SAN), mysql se optimizó y se monitorea continuamente. Hubo algunos problemas en el pasado relacionados con E / S (algunos emitidos con el enlace entre los servidores y el almacenamiento SAN).

No pudimos precisar el problema porque, al ejecutarse en metal desnudo (sin virtualización, misma configuración), esto nunca sucede, en condiciones de alto estrés (ejecutando escenarios de prueba de asedio + carga, sin caché).

¿Alguien más tiene problemas similares?

ACTUALIZAR:

reindexToda la búsqueda se movió a una tabla temporal (por lo que no bloquea la tabla principal utilizada por la producción, luego cambia el nombre de la tabla tmp). Entonces, el proceso de reindexación no interfiere con los visitantes que buscan en el sitio web. https://github.com/magendooro/magento-fulltext-reindex felicitaciones a carco

Parece un error central / regresión que vimos en 1.7 donde el bloque y la caché de colección no funcionaban de manera efectiva para el menú de navegación ( catalog/navigation/top.phtml).

Puede probar eliminándolo o simplemente capturar temporalmente la salida en un archivo con un archivo ob_starty servirlo desde un archivo estático / memcache.

Además, el hardware que está utilizando no suena enorme y se ve por debajo del especificado para el tamaño de la tienda que tiene. Probablemente también haya un cuello de botella de E / S: almacenamiento SAN + red congestionada = bajo rendimiento.

-

Como solución cruda, puede ajustar la clase de bloque para la navegación (volcado get_class($this)) top.phtmlpara identificarlo.

Esto permitirá el almacenamiento en caché en todo el sitio, sin el almacenamiento en caché a nivel de categoría que invocó la nueva versión. También vale la pena eliminar la is_activeclase del renderizador de árbol si hace esto para evitar que los elementos de menú aleatorios aparezcan seleccionados (e implemente una alternativa JS en su lugar).

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;
}

Reemplazar función en

app / code / core / Mage / Catalog / Helper / Category / 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;
}

En nuestro caso, todo se redujo a esta lenta consulta:

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')

desde app / code / core / Mage / Sitemap / Model / Resource / Catalog / Product.php .

Se cuelga debido a la instrucción category_id IS NULL . MySQL por alguna razón no utilizó un índice.

Quitar category_id IS NULL y establecer id_path REGEXP '^ product / [0-9] + $' solucionó el problema.

Copie app / code / core / Mage / Catalog / Helper / Product / Url / Rewrite.php a app / code / local / Mage / Catalog / Helper / Product / Url / Rewrite.php y agregue esta función:

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;
}

Luego copie app / code / core / Mage / Sitemap / Model / Resource / Catalog / Product.php a app / code / local / Mage / Sitemap / Model / Resource / Catalog / Product.php y cambie la línea 72 a:

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

Originalmente tomado de https://www.goivvy.com/blog/solved-magento-stuck-generating-google-sitemap-large-website