MySQL sigue colgando (consultas bloqueadas al enviar datos)


10

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


¿Estás seguro de que corrieron rápido? La alternativa puede ser que el menú de navegación esté en caché. El uso de un índice de Afaik no es fácil porque no hay índice sobre category_ud, is_system y path. Y la ruta es como, así que MySQL tiene aquí un problema real. No estoy db export por cierto ;-) Solo 2cents
Fabian Blechschmidt

1
esa selección se ejecuta en menos de 1s. las consultas siguen acumulándose cuando la primera permanece enviando datos ...
FlorinelChis

1
FWIW He visto el mismo problema.
philwinkle

@philwinkle ¿cómo es tu configuración de búsqueda? ¿texto completo?
FlorinelChis

1
github.com/magendooro/magento-fulltext-reindex esto nos ayudó y decidió publicar el código fuente.
FlorinelChis

Respuestas:


4

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

anteriormente asignamos 32 núcleos y 92 Gb de ram (y cambiamos la configuración de mysql en consecuencia, el mismo resultado): el servidor tiene 64 núcleos y 184 gb de ram (es por eso que estaba diciendo que es enorme) ... lo siento, no mencioné es Magento Enterprise 1.12. monitoreamos el tráfico de la red, no vimos nada que apuntara a un cuello de botella (tuvimos un problema antes, el conector de fibra no funcionaba correctamente, fue reemplazado).
FlorinelChis

Enterprise 1.12 es CE 1.7: son la misma base de código. Entonces el error los afectará a ambos. Pruebe lo que dije (codifique la navegación superior y desactive las categorías en la navegación en capas) y podrá confirmar. Más hardware no hará la diferencia si el software no está configurado correctamente para usarlo.
Ben Lessani - Sonassi

Voy a editar mi respuesta y agregaré un código hacky para que lo uses para confirmar
Ben Lessani - Sonassi

Es un buen lugar para comenzar, pondré algo en su lugar y veré si todavía falla en 1 semana :)
FlorinelChis

3

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

2

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

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.