다음과 같은 상황이 있습니다.
일주일에 약 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
답변
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;
}
답변
에 기능 교체
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 에서 가져 왔습니다.