Tengo la siguiente situación:
Aproximadamente 5 veces a la semana (no relacionado con ninguna situación específica, como el borrado de caché, el pico de tráfico), algunas consultas están bloqueadas al enviar datos ( 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
segundo:
> 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
Estas consultas están relacionadas con la generación del menú de navegación. Se ejecutan sin problemas y muy rápido todo el tiempo.
Pocas veces al mes, algunas otras consultas se atascan al enviar datos o al esperar el bloqueo de la tabla:
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`)
(búsqueda relacionada)
Información adicional:
- core_url_rewrite - 3M registros (30 sitios web, 100k productos)
- catalog_category_flat_store_ * - 2000 registros (el uso de categorías planas está habilitado)
Esto se ejecuta en una configuración que usa vmware en un hardware enorme (mysql master tiene 8 núcleos asignados y 64 Gb de RAM, discos SSD en un almacenamiento SAN), mysql se optimizó y se monitorea continuamente. Hubo algunos problemas en el pasado relacionados con E / S (algunos emitidos con el enlace entre los servidores y el almacenamiento SAN).
No pudimos precisar el problema porque, al ejecutarse en metal desnudo (sin virtualización, misma configuración), esto nunca sucede, en condiciones de alto estrés (ejecutando escenarios de prueba de asedio + carga, sin caché).
¿Alguien más tiene problemas similares?
ACTUALIZAR:
reindexToda la búsqueda se movió a una tabla temporal (por lo que no bloquea la tabla principal utilizada por la producción, luego cambia el nombre de la tabla tmp). Entonces, el proceso de reindexación no interfiere con los visitantes que buscan en el sitio web. https://github.com/magendooro/magento-fulltext-reindex felicitaciones a carco