Geïndexeerde indexen worden constant uitgevoerd en indexer_rendex_all_invalid

Dit artikel biedt een mogelijke oplossing voor het probleem wanneer er voor uw site prestatieproblemen optreden die worden veroorzaakt door voortdurend opnieuw indexeren. Dit wordt veroorzaakt door de uitsnijdtaak indexer_reindex_all_invalid die continu wordt uitgevoerd en caches die worden schoongemaakt bij herindexering.

Beschrijving description

Omgeving

Adobe Commerce (wolk & op-gebouw) 2.4.0+ (aangezien de Toestemmingen van de Categorie een Adobe-Commerce-enige eigenschap is, zal het Magento Open Source niet beïnvloeden.)

Probleem

In New Relic One-foutlogboeken moet indexer_update_all_views vele keren worden weergegeven met een tijd van > 1 seconde (bijvoorbeeld dat het iets verwerkt).

Oorzaak

Wanneer de belangrijkste Adobe Commerce-importer wordt uitgevoerd (handmatig of door uitsnijden), wordt een set plug-ins voor meerdere kernmodules uitgevoerd om te bepalen welke indexen ongeldig moeten worden gemaakt.

De kwestie komt voor wanneer de module van de Toestemmingen van de Categorie in Commerce Admin wordt toegelaten. Als dit waar is, dan maakt de stop van de module altijd de indexen van het Product & van de Categorie (en verbonden indexen) onbruikbaar wanneer het invoeren wordt uitgevoerd. Als de standaardinvoertypes worden onderzocht, dan beïnvloeden zij allen Toestemmingen van de Categorie . Ongeldige validatie wordt verwacht.

Bovendien wanneer een plaats B2B modules heeft toegelaten, als Gedeelde Catalogus wordt geactiveerd, zet het Vergunningen van de Categorie aan en sluit . Het uitzetten van Gedeelde Catalogus zal Toestemmingen van de Categorie ontgrendelen, maar niet het uitzetten.

het Controleren van cron logboeken in uw gegevensbestand MySQL:

Als u login in uw gegevensbestand MySQL, kunnen zij uw cron logboek voor het opnieuw indexeren alle indexen proces controleren.
Dit zou vele malen moeten verschijnen, maar de belangrijke factor is dat het proces één van twee mogelijke dingen doet.

Het proces kan slechts één van deze twee dingen doen:

Normaal gesproken wilt u veel exemplaren van het proces zien, maar met een uitvoeringstijd van minder dan 1 seconde.
Een handelaar kan deze vraag daarom gebruiken MySQL om transacties te vinden die meer dan 1 seconde nemen om in werking te stellen:

SELECT TIMESTAMPDIFF(SECOND, executed_at, finished_at) AS period FROM cron_schedule WHERE job_code = 'indexer_reindex_all_invalid' HAVING period > 1

U kunt zien hoe lang een periode door loopt wordt geregistreerd:

SELECT executed_at FROM cron_schedule WHERE job_code = 'indexer_reindex_all_invalid' AND executed_at IS NOT NULL ORDER BY executed_at ASC LIMIT 1;

Als dit u geen lange genoeg periode geeft om een juiste beoordeling te maken, dan kunt u de tijd verhogen een succesvol cron proces in het logboek na dit ​ Gewas (geplande taken) wordt gehouden ​ gids en het verhogen van de waarde van het Leven van de Geschiedenis van het Succes (het gebrek is slechts 60 minuten).

Resolutie resolution

Breid Magento\CatalogPermissions\Model\Indexer\Plugin\Import uit, zodat de aangepaste importer niet wordt opgenomen in de methode afterImportSource .

public function afterImportSource(\Magento\ImportExport\Model\Import $subject, $import)
    {
        if ($this->config->isEnabled() && $subject->getEntity() !== 'ENTITY_CODE') {
            $this->indexerRegistry->get(\Magento\CatalogPermissions\Model\Indexer\Category::INDEXER_ID)->invalidate();
            $this->indexerRegistry->get(\Magento\CatalogPermissions\Model\Indexer\Product::INDEXER_ID)->invalidate();
        }
        return $import;
    }

Hierbij is ENTITY_CODE de waarde die wordt gebruikt voor de parameter entiteitsnaam in het import.xml -bestand voor de aangepaste importer.

Gerelateerde lezing

​ vorm cron banen ​ in de Gids van de Configuratie van de Verrichtingen van Adobe Commerce.