MySQL continua a bloccarsi (query bloccate sull'invio di dati)

Ho la seguente situazione:

Circa 5 volte a settimana (non correlato a situazioni specifiche come la cancellazione della cache, il picco di traffico) alcune query sono bloccate sull'invio di dati ( 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

il secondo:

> 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

Queste query sono correlate alla generazione del menu di navigazione. Funzionano senza problemi e molto velocemente per tutto il tempo.

Poche volte al mese alcune altre query rimangono bloccate su dati seding o in attesa del blocco della tabella:

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

(ricerca relativa)

Informazioni addizionali:

• core_url_rewrite - 3M records (30 siti Web, 100k prodotti)
• catalog_category_flat_store_ * - 2000 record (è abilitato l'uso di categorie piatte)

Questo è in esecuzione su una configurazione che utilizza vmware su hardware enorme (master mysql ha 8 core allocati e 64 GB di RAM, dischi SSD su una memoria SAN), mysql è stato ottimizzato e viene monitorato continuamente. Ci sono stati alcuni problemi in passato relativi all'I / O (alcuni problemi con il collegamento tra i server e l'archiviazione SAN).

Non siamo riusciti a individuare il problema perché l'esecuzione su bare metal (nessuna virtualizzazione, stessa configurazione) ciò non accade mai, in condizioni di stress elevato (esecuzione di scenari di assedio + carico test, nessuna cache).

Qualcun altro ha problemi simili?

AGGIORNARE:

reindex Tutta la ricerca è stata spostata in una tabella temporanea (quindi non blocca la tabella principale utilizzata dalla produzione, quindi rinomina la tabella tmp). Pertanto, il processo reindex non interferisce con i visitatori che effettuano ricerche nel sito Web. https://github.com/magendooro/magento-fulltext-reindex complimenti a carco

Sembra un bug di base / regressione che abbiamo visto in 1.7 dove il blocco e la cache di raccolta non funzionavano in modo efficace per il menu di navigazione ( catalog/navigation/top.phtml).

Puoi testarlo rimuovendolo o semplicemente catturare temporaneamente l'output in un file con un ob_starte servirlo da un file statico / memcache.

Inoltre, l'hardware che stai utilizzando non sembra enorme e sembra meno specificato per le dimensioni del negozio che hai. Probabilmente esiste anche un collo di bottiglia di I / O: memoria SAN + rete congestionata = prestazioni scadenti.

-

Come soluzione grezza, è possibile regolare la classe di blocco per la navigazione (dump get_class($this)) top.phtmlper identificarla.

Ciò consentirà la memorizzazione nella cache di tutto il sito, senza la memorizzazione nella cache a livello di categoria richiamata dalla nuova versione. Vale anche la pena rimuovere la is_activeclasse dal renderer dell'albero se si fa questo per evitare che voci di menu casuali appaiano selezionate (e invece implementare un'alternativa 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;
}

Sostituisci funzione a

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

Nel nostro caso è arrivato a questa query lenta:

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

da app / code / core / Mage / Sitemap / Modello / Risorse / Catalogo / Product.php .

Si blocca a causa dell'istruzione IS NULL di category_id . MySQL per qualche motivo non utilizzava un indice.

La rimozione di category_id IS NULL e l'impostazione di id_path REGEXP '^ product / [0-9] + $' hanno risolto il problema.

Copia app / codice / core / Mage / Catalog / Helper / Product / Url / Rewrite.php in app / code / local / Mage / Catalog / Helper / Product / Url / Rewrite.php e aggiungi questa funzione:

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

Quindi copia app / codice / core / Mage / Sitemap / Modello / Risorsa / Catalogo / Product.php in app / codice / locale / Mage / Sitemap / Modello / Risorsa / Catalogo / Product.php e cambia la riga 72 in:

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

Tratto in origine da https://www.goivvy.com/blog/solved-magento-stuck-generating-google-sitemap-large-website