MySQL bleibt hängen (Abfragen bleiben beim Senden von Daten hängen)

Ich habe folgende Situation:

Ungefähr 5 Mal pro Woche (nicht im Zusammenhang mit einer bestimmten Situation wie Cache löschen, Verkehrsspitze) bleiben einige Abfragen beim Senden von Daten hängen ( 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

das Zweite:

> 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

Diese Abfragen beziehen sich auf das Generieren des Navigationsmenüs. Sie laufen ohne Probleme und sehr schnell.

Einige Male im Monat bleiben einige andere Abfragen beim Aussetzen von Daten oder beim Warten auf die Tabellensperre hängen:

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

(suchbezogen)

Zusätzliche Information:

• core_url_rewrite - 3 Millionen Datensätze (30 Websites, 100.000 Produkte)
• catalog_category_flat_store_ * - 2000 Datensätze (flache Kategorien verwenden ist aktiviert)

Dies läuft auf einem Setup mit VMware auf einer riesigen Hardware (MySQL-Master verfügt über 8 zugewiesene Kerne und 64 GB RAM, SSD-Festplatten in einem SAN-Speicher), MySQL wurde optimiert und wird kontinuierlich überwacht. In der Vergangenheit gab es einige Probleme im Zusammenhang mit E / A (einige Probleme mit der Verbindung zwischen den Servern und dem SAN-Speicher).

Wir konnten das Problem nicht genau bestimmen, da dies unter Bare-Metal-Bedingungen (keine Virtualisierung, gleiche Konfiguration) unter Bedingungen mit hohem Stress (Ausführen von Belagerungs- + Lasttestszenarien, kein Cache) niemals vorkommt.

Hat noch jemand ähnliche Probleme?

AKTUALISIEREN:

Die reindexAll-Suche wurde in eine temporäre Tabelle verschoben (damit die von der Produktion verwendete Haupttabelle nicht gesperrt und die tmp-Tabelle umbenannt wird). Der Neuindizierungsprozess beeinträchtigt also nicht die Besucher, die die Website durchsuchen. https://github.com/magendooro/magento-fulltext-reindex ein großes Lob an carco

Es sieht aus wie ein Kernfehler / eine Kernregression, die wir in 1.7 gesehen haben, als der Block- und Sammlungscache für das Navigationsmenü ( catalog/navigation/top.phtml) nicht effektiv funktionierte .

Sie können testen, indem Sie es entfernen oder die Ausgabe nur vorübergehend in einer Datei mit einem erfassen ob_startund aus einer statischen Datei / einem statischen Memcache bereitstellen.

Außerdem klingt die von Ihnen verwendete Hardware nicht sehr groß und sieht für die Größe des Geschäfts, das Sie haben, unter angegeben aus. Wahrscheinlich gibt es auch dort einen E / A-Engpass - SAN-Speicher + überlastetes Netzwerk = schlechte Leistung.

- -

Als grobe Lösung können Sie die Blockklasse für die Navigation (Dump get_class($this)) anpassen top.phtml, um sie zu identifizieren.

Dies ermöglicht ein Site-weites Caching ohne das Caching auf Kategorieebene, das von der neuen Version aufgerufen wurde. Es lohnt sich auch, die is_activeKlasse aus dem Baum-Renderer zu entfernen, wenn Sie dies tun, um zu vermeiden, dass zufällige Menüelemente ausgewählt erscheinen (und stattdessen eine JS-Alternative implementieren).

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

Funktion bei ersetzen

app / code / core / Mage / Katalog / Helfer / Kategorie / 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;
}

In unserem Fall kam es auf diese langsame Abfrage an:

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

aus app / code / core / Mage / Sitemap / Modell / Ressource / Katalog / Product.php .

Es hängt aufgrund der Anweisung category_id IS NULL . MySQL hat aus irgendeinem Grund keinen Index verwendet.

Das Entfernen von category_id IS NULL und das Setzen von id_path REGEXP '^ product / [0-9] + $' hat das Problem behoben.

Kopieren Sie app / code / core / Mage / Catalog / Helper / Product / Url / Rewrite.php in app / code / local / Mage / Catalog / Helper / Product / Url / Rewrite.php und fügen Sie diese Funktion hinzu:

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

Kopieren Sie dann app / code / core / Mage / Sitemap / Model / Resource / Catalog / Product.php nach app / code / local / Mage / Sitemap / Model / Resource / Catalog / Product.php und ändern Sie Zeile 72 in:

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

Ursprünglich von https://www.goivvy.com/blog/solved-magento-stuck-generating-google-sitemap-large-website entnommen