다음과 같은 상황이 있습니다.
일주일에 약 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