J'ai la situation suivante:
Environ 5 fois par semaine (sans rapport avec une situation spécifique comme la suppression du cache, le pic de trafic) certaines requêtes sont bloquées lors de l'envoi de données ( 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
deuxième:
> 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
Ces requêtes sont liées à la génération du menu de navigation. Ils fonctionnent sans aucun problème et très rapidement tout le temps.
Quelques fois par mois, certaines autres requêtes se bloquent sur les données d'amorçage ou attendent le verrouillage de la table:
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`)
(liée à la recherche)
Information additionnelle:
- core_url_rewrite - Enregistrements 3M (30 sites Web, 100 000 produits)
- catalog_category_flat_store_ * - 2000 enregistrements (l'utilisation des catégories plates est activée)
Cela fonctionne sur une configuration utilisant vmware sur un matériel énorme (le maître mysql a 8 cœurs alloués et 64 Go de RAM, des disques SSD sur un stockage SAN), mysql a été optimisé et surveillé en continu. Il y avait dans le passé des problèmes liés aux E / S (certains sont liés au lien entre les serveurs et le stockage SAN).
Nous n'avons pas pu identifier le problème, car en cours d'exécution sur du métal nu (pas de virtualisation, même configuration), cela ne se produit jamais, dans des conditions de stress élevé (exécution de scénarios de test de siège + charge, pas de cache).
Quelqu'un d'autre a des problèmes similaires?
METTRE À JOUR:
reindexAll recherche a été déplacée vers une table temporaire (donc elle ne verrouille pas la table principale utilisée par la production, puis renomme la table tmp). Ainsi, le processus de réindexation n'interfère pas avec les visiteurs qui recherchent le site Web. https://github.com/magendooro/magento-fulltext-reindex bravo à carco
Réponses:
Il ressemble à un bogue / régression de base que nous avons vu dans 1.7 où le cache de bloc et de collection ne fonctionnait pas efficacement pour le menu de navigation (
catalog/navigation/top.phtml
).Vous pouvez tester en le supprimant, ou simplement capturer temporairement la sortie dans un fichier avec un
ob_start
et la servir à partir d'un fichier statique / memcache.De plus, le matériel que vous utilisez ne semble pas énorme et semble sous-spécifié pour la taille du magasin que vous avez. Il y a probablement aussi un goulot d'étranglement d'E / S - stockage SAN + réseau encombré = performances médiocres.
-
En tant que solution brute, vous pouvez ajuster la classe de bloc pour la navigation (vidage
get_class($this)
) danstop.phtml
pour l'identifier.Cela permettra la mise en cache à l'échelle du site, sans la mise en cache au niveau de la catégorie que la nouvelle version a invoquée.
is_active
Cela vaut également la peine de supprimer la classe du rendu d'arbre si vous faites cela pour éviter que des éléments de menu aléatoires n'apparaissent sélectionnés (et implémentez une alternative JS à la place).la source
Remplacer la fonction à
app / code / core / Mage / Catalogue / Helper / Category / Url / Rewrite.php:
la source
Dans notre cas, cela se résumait à cette lente requête:
depuis app / code / core / Mage / Sitemap / Model / Resource / Catalog / Product.php .
Il se bloque en raison de l' instruction category_id IS NULL . MySQL pour une raison quelconque n'a pas utilisé d'index.
La suppression de category_id IS NULL et la définition de id_path REGEXP '^ product / [0-9] + $' ont résolu le problème.
Copiez app / code / core / Mage / Catalog / Helper / Product / Url / Rewrite.php vers app / code / local / Mage / Catalog / Helper / Product / Url / Rewrite.php et ajoutez cette fonction:
Copiez ensuite app / code / core / Mage / Sitemap / Model / Resource / Catalog / Product.php vers app / code / local / Mage / Sitemap / Model / Resource / Catalog / Product.php et changez la ligne 72 en:
Tiré à l'origine de https://www.goivvy.com/blog/solved-magento-stuck-generating-google-sitemap-large-website
la source