Beheerde waarschuwingen voor Adobe Commerce: waarschuwing over geheugengebruik

De pagina van de Infrastructuur van APM van het gebruik New Relic om hoogste geheugen-intensieve processen te identificeren.Voor stappen, verwijs naar New Relic [de pagina van de Gastheren van de Controle van de Infrastructuur: Processes lusje]. Als services als Redis of MySQL de belangrijkste bron van geheugenverbruik zijn, kunt u het volgende proberen:

• Controleer of u de meest recente versie hebt. In nieuwere versies kunnen soms geheugenlekken worden gecorrigeerd. Als u niet over de nieuwste versie beschikt, kunt u een upgrade uitvoeren. Voor stappen, verwijs naar Diensten van de Veranderingin Commerce op de Gids van de Wolk.
• Als u nog steeds de bron van verhoogd geheugenverbruik niet kunt identificeren, controleert u op MySQL-problemen zoals langdurige query's, primaire sleutels niet gedefinieerd en dubbele indexen. Voor stappen, verwijs naar Veelvoorkomende gegevensbestandKwesties in Adobe Commerce op wolkeninfrastructuurin het Playbook van de Implementatie van Commerce.
• Als er geen MySQL problemen zijn, controleer dan op PHP problemen. Herzie lopende processen door ps aufx in CLI/Terminal in werking te stellen. In de eindoutput, zult u cron banen en processen zien die momenteel worden uitgevoerd. Controleer de uitvoer op de uitvoeringstijd van het proces. Als er een kruin met een lange uitvoeringstijd is, kan de kruin hangen. Verwijs naar Trage prestaties, langzame en langlopende kronenen baan van het Gewas die in "lopende"statusin de Kennisbank van de Steun van Commerce voor het oplossen van problemenstappen wordt geplakt.

Als u nog worstelt om de bron van het probleem te identificeren, gebruik {de pagina van de Transactie van 0} APM New Relic om transacties met prestatieskwesties te identificeren:

• Transacties sorteren door oplopende Apdex scores. Apdexverwijst naar gebruikerstevredenheid aan de reactietijd van uw Webtoepassingen en de diensten. A laag Apdex scorekan op een knelpunt (een transactie met een hogere reactietijd) wijzen. Doorgaans is dit de database, Redis of PHP. Voor stappen, verwijs naar de transacties van de Mening van New Relic met hoogste Apdex ontevredenheid.
• De transacties van de soort door hoogste productie, de langzaamste gemiddelde reactietijd, het meest tijdrovend, en andere drempels. Voor stappen, verwijs naar New Relic Vondst specifieke prestatiesproblemen. Als u nog worstelt om de kwestie te identificeren, gebruik New Relic APM's pagina van de Infrastructuur van de APM.

Als u niet de oorzaak van verhoogde geheugenconsumptie kunt identificeren, herzie recente tendensen om kwesties met recente codeplaatsingen of configuratieveranderingen (bijvoorbeeld, nieuwe klantengroepen en grote veranderingen in de catalogus) te identificeren. U wordt aangeraden de afgelopen zeven dagen van activiteit te controleren op correlaties in codeimplementaties of -wijzigingen.

Als de bovenstaande methoden u niet helpen de oorzaak en/of oplossing binnen een redelijke tijd te vinden, vraagt u om een upgrade of zet u de site in de onderhoudsmodus als u dat nog niet hebt gedaan. Voor stappen, verwijs naar hoe te om tijdelijke resizein de Kennisbank van de Steun van Commerce en toe te laten of onderhoudswijzein de Gids van de Installatie van Commerce onbruikbaar te maken.

Als de upsize de plaats aan normale verrichtingen terugkeert, overweeg om permanent te verzoeken (uw Team van de Rekening van Adobe), of probeer om het probleem in uw Dedicated Staging te reproduceren door een ladingstest in werking te stellen en vragen te optimaliseren, of code die druk op de diensten vermindert. Verwijs naar Lading en stress het testenin Commerce op de Gids van de Wolk.