Adobe Commerce上的托管警报：内存严重警报
本文提供了在New Relic中收到Adobe Commerce的内存严重警报时的故障排除步骤。 需要立即采取措施来解决问题。
受影响的产品和版本
云基础架构专业版上的所有Adobe Commerce版本都规划了架构。
问题
如果您已为Adobe Commerce🔗注册了个托管警报，并且一个或多个警报阈值已超出，则您将在New Relic中收到托管警报。 这些警报由Adobe开发，旨在通过支持和工程部门的分析为客户提供一组标准。
做！
- 中止任何计划的部署，直到清除此警报。
- 如果您的网站处于或完全无响应，请立即将网站置于维护模式。 有关步骤，请参阅《Commerce安装指南》中的启用或禁用维护模式。 确保将您的IP添加到免除IP地址列表，以确保您仍然能够访问站点进行故障排除。 有关步骤，请参阅《Commerce安装指南》中的维护免除IP地址列表。
不要！
- 启动其他营销活动，这可能会给您的网站带来其他页面查看次数。
- 运行索引器或其他cron，这可能会在CPU或磁盘上造成额外的压力。
- 执行任何主要管理任务(即Commerce管理、数据导入/导出)。
- 清除缓存。
如果您在调查并解决警报原因之前执行了任何“不响应”操作，则您的网站可能会变得无响应（如果您尚未经历网站中断）。
解决方案
按照以下步骤确定原因并排除故障。
-
检查Adobe Commerce支持票证是否存在。 有关步骤，请参阅Commerce支持知识库中的跟踪您的支持工单。 支持人员可能已经收到New Relic阈值警报，已创建票证并开始处理此问题。 如果不存在票证，请创建一个。 票证应包含以下信息：
- 联系原因：选择 New Relic 收到的严重警报
- 警报描述
- New Relic 事件链接。 这包含在您的Adobe Commerce托管警报中。
-
使用New Relic APM的“基础架构”页识别占用大量内存的顶级进程。 有关步骤，请参阅New Relic 基础结构监视主机页面：进程选项卡：
- 如果Redis、MySQL或PHP等服务是内存消耗的主要来源，请尝试以下操作：
1.检查您是否使用最新版本。 较新版本有时可以修复内存泄漏。 如果您不是最新版本，请考虑升级。 有关步骤，请参阅Commerce on Cloud指南中的更改服务。
- 如果Redis、MySQL或PHP等服务是内存消耗的主要来源，请尝试以下操作：
-
如果服务问题与版本无关，请尝试以下操作：
-
MySQL：检查长时间运行的查询、未定义主键以及重复索引等问题。 有关步骤，请参阅Adobe Commerce实施行动手册中的Commerce上最常见的数据库问题。
-
Redis：如果Redis是内存消耗的顶级源，则提交支持票证。
-
PHP：如果PHP是内存消耗的最大来源，请在CLI/终端中运行
ps aufx来检查正在运行的进程。 在终端输出中，您将看到当前正在执行的cron作业和进程。 检查进程执行时间的输出。 如果存在执行时间较长的cron，则该cron可能会挂起。 有关故障排除步骤，请参阅Commerce支持知识库中的性能缓慢、运行缓慢且时间较长和Cron作业停留在“正在运行”状态。 -
如果您仍在努力找出问题的根源，请使用New Relic APM的“事务”页来识别具有性能问题的事务：
- 按升序Apdex分数对事务排序。 Apdex指用户对Web应用程序和服务的响应时间的满意度。 Apdex score可能表示瓶颈（响应时间较长的事务）。 通常是数据库 Redis或PHP。 有关步骤，请参阅New Relic 查看满意度最高的 Apdex 事务。
- 按最高吞吐量、最慢的平均响应时间、最耗时的阈值和其他阈值对事务进行排序。 有关步骤，请参阅New Relic [查找具体性能问题]。 如果您仍在努力识别问题，请使用New Relic APM的基础结构页面。
-
如果您无法确定内存消耗增加的原因，请查看近期趋势以确定近期代码部署或配置更改（例如，新客户组和目录的大幅更改）中存在的问题。 建议您查看过去7天的活动，以了解代码部署或更改中的任何关联。
-
如果上述方法不能帮助您在合理的时间内找到原因和/或解决方案，请请求升级站点，或将站点置于维护模式（如果尚未这样做）。 有关步骤，请参阅Commerce支持知识库中的如何请求调整临时大小，以及《Commerce安装指南》中的启用或禁用维护模式。
-
如果升级使站点恢复正常运营，请考虑请求永久升级(联系您的Adobe客户团队)，或尝试通过运行负载测试和优化查询或在专用暂存中重现问题，或运行降低服务压力的代码。 请参阅Commerce on Cloud指南中的负载和压力测试。