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

これらのクエリは、ナビゲーションメニューの生成に関連しています。問題なく動作し、常に非常に高速です。

1か月に数回、他のいくつかのクエリがデータのセディングまたはテーブルロックの待機でスタックします。

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のウェブサイト、10万の製品）
• catalog_category_flat_store_ *-2000レコード（フラットカテゴリの使用が有効）

これは、いくつかの巨大なハードウェア上でvmwareを使用するセットアップで実行され（mysqlマスターには8コアが割り当てられ、64GbのRAM、SANストレージ上のSSDディスク）、mysqlは最適化され、継続的に監視されます。過去にI / Oに関連するいくつかの問題がありました（サーバーとSANストレージ間のリンクに関するいくつかの問題）。

ベアメタル（仮想化なし、同じ構成）で実行しているため、高負荷条件（包囲+負荷テストシナリオ、キャッシュなし）でこれが発生しないため、問題を特定できませんでした。

他に同様の問題がある人はいますか？

更新：

reindexAll検索は一時テーブルに移動されました（プロダクションで使用されるメインテーブルをロックせず、tmpテーブルの名前を変更しません）。したがって、インデックスの再作成プロセスは、Webサイトを検索する訪問者の妨げにはなりません。 https://github.com/magendooro/magento-fulltext-reindex kudos to carco

1.7で確認したコアバグ/回帰のように見えますが、ブロックとコレクションキャッシュがナビゲーションメニュー（catalog/navigation/top.phtml）で効果的に機能していませんでした。

削除してテストするか、出力を一時的にファイルにキャプチャob_startして静的ファイル/ memcacheから提供することができます。

また、使用しているハードウェアは大きく聞こえず、お持ちのストアのサイズに対して指定されたサイズよりも低く見えます。おそらくそこにもI / Oボトルネックがあります-SANストレージ+ネットワークの混雑=パフォーマンスの低下。

-

大まかな解決策として、ナビゲーション（dump 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 / 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;
}

私たちの場合、それはこの遅いクエリに帰着しました：

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

アプリ/コード/コア/メイジ/サイトマップ/モデル/リソース/カタログ/ Product.php。

category_id IS NULLステートメントが原因でハングします。MySQLは何らかの理由でインデックスを使用しませんでした。

category_id IS NULLを削除し、id_path REGEXP '^ product / [0-9] + $'を設定して問題を修正しました。

コピーアプリ/コード/コア/メイジ/カタログ/ヘルパー/プロダクト/ URL / Rewrite.phpにアプリ/コード/ローカル/メイジ/カタログ/ヘルパー/プロダクト/ 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;
}

次にapp / code / core / Mage / Sitemap / Model / Resource / Catalog / Product.phpをapp / code / local / 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から取得