MySQL이 계속 멈춤 (데이터 전송시 쿼리가 멈춤)


10

다음과 같은 상황이 있습니다.

일주일에 약 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

이러한 쿼리는 탐색 메뉴 생성과 관련이 있습니다. 그들은 아무런 문제없이 항상 매우 빠르게 실행됩니다.

한 달에 몇 번 다른 쿼리가 데이터를 시드하거나 테이블 잠금을 기다리는 중입니다.

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 개 웹 사이트, 100k 제품)
  • catalog_category_flat_store_ *-2000 개의 레코드 (플랫 범주 사용 가능)

이것은 거대한 하드웨어 (mysql 마스터에는 8 개의 코어가 할당되어 있고 64Gb의 RAM, SAN 스토리지의 SSD 디스크가 있음)에서 vmware를 사용하여 설정에서 실행 중이며 mysql은 최적화되어 지속적으로 모니터링됩니다. 과거에는 I / O와 관련된 몇 가지 문제가있었습니다 (일부 서버와 SAN 스토리지 사이의 링크 관련 문제).

베어 메탈 (가상화, 동일한 구성 없음)에서 실행하면 스트레스가 많은 조건 (공성 +로드 테스트 시나리오 실행, 캐시 없음)에서 발생하지 않으므로 문제를 정확히 파악할 수 없습니다.

비슷한 문제가있는 사람이 있습니까?

최신 정보:

reindex 모든 검색이 임시 테이블로 이동되었으므로 프로덕션에서 사용하는 기본 테이블을 잠그지 않고 tmp 테이블의 이름을 바꿉니다. 따라서 재색 인 프로세스는 웹 사이트를 검색하는 방문자를 방해하지 않습니다. https://github.com/magendooro/magento-fulltext-reindex to carco to carco


그들이 빨리 달렸나요? 대안은 네비게이션 메뉴가 캐시 될 수있다. Afaik은 category_ud, is_system 및 path에 대한 인덱스가 없기 때문에 인덱스 사용법이 쉽지 않습니다. 그리고 경로는 비슷합니다. 따라서 MySQL은 실제 문제가 있습니다. 나는 DB 수출 btw 아니야 ;-) 그냥 2cents
Fabian Blechschmidt

1
그 선택은 1s에서 실행됩니다. 첫 번째 질문이 데이터를 계속 보낼 때 쿼리가 계속 누적됩니다 ...
FlorinelChis

1
FWIW 나는 같은 문제를 보았다.
philwinkle

@philwinkle 검색 설정은 어떻습니까? 전문?
FlorinelChis

1
github.com/magendooro/magento-fulltext-reindex 이것은 우리에게 도움이되었고 소스 코드를 공개하기로 결정했습니다.
FlorinelChis

답변:


4

1.7에서 블록 및 컬렉션 캐시가 탐색 메뉴에서 효과적으로 작동하지 않는 핵심 버그 / 회귀처럼 보입니다 ( catalog/navigation/top.phtml).

이를 제거하여 테스트하거나 또는 출력을 파일로 임시 캡처하여 ob_start정적 파일 / memcache에서 제공 할 수 있습니다.

또한 사용중인 하드웨어가 크게 들리지 않으며 보유하고있는 상점의 크기에 맞게 지정되어 있습니다. SAN 스토리지 + 혼잡 네트워크 = 성능 저하와 같은 I / O 병목 현상이있을 수 있습니다.

-

원유 솔루션으로 탐색 (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;
}

우리는 이전에 32 개의 코어와 92Gb의 램을 할당했으며 (그리고 그에 따라 mysql 구성을 변경했습니다. 동일한 결과)-서버에는 64 개의 코어와 184 기가 바이트의 램이 있습니다 (그래서 나는 그것이 거대하다고 말한 이유입니다 ...), 언급하지 않았습니다. Magento Enterprise 1.12입니다. 네트워크 트래픽에 병목 현상이 발생하지 않는지 모니터링했습니다 (이전에 문제가 발생했습니다. 광섬유 커넥터가 제대로 작동하지 않아 교체되었습니다).
FlorinelChis

Enterprise 1.12는 CE 1.7이며 동일한 코드 기반입니다. 따라서 버그는 둘 다에 영향을 미칩니다. 내가 말한 것을 시도하고 (상위 탐색을 하드 코딩하고 계층 탐색에서 카테고리를 비활성화하십시오) 확인하실 수 있습니다. 소프트웨어가 올바르게 사용하도록 설정되어 있지 않으면 더 많은 하드웨어가 차이를 만들지 않을 것입니다.
Ben Lessani-Sonassi

나는 내 대답을 편집하고 일부 추가거야 해키 당신이 확인에 사용할 수 있도록 코드를
벤 Lessani을 - Sonassi

시작하기에 좋은 곳입니다. 무언가를 제자리에 놓고 1 주일 이내에 여전히 충돌하는지 확인합니다. :)
FlorinelChis

3

에 기능 교체

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

우리의 경우 다음과 같은 느린 쿼리가 발생했습니다.

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.phpapp / 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 에서 가져 왔습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.