Adobe Commerce上的托管警报：CPU严重警报
本文提供了在New Relic中收到Adobe Commerce的CPU严重警报时的故障排除步骤。 需要立即采取措施来解决问题。 根据您选择的警报通知渠道，警报将类似于以下内容。
受影响的产品和版本
Adobe Commerce on cloud infrastructure Pro计划架构
问题
如果您已为New Relic🔗注册了个托管警报，并且一个或多个警报阈值已超出，则您将在Adobe Commerce中收到托管警报。 这些警报由Adobe Commerce开发，旨在通过支持和工程部门的分析为客户提供一组标准。
做！：
- 中止任何计划的部署，直到清除此警报。
- 如果您的网站处于或完全无响应，请立即将网站置于维护模式。 有关步骤，请参阅我们的开发人员文档中的安装指南>启用或禁用维护模式。 确保将您的IP添加到免除IP地址列表，以确保您仍然能够访问站点进行故障排除。 有关步骤，请参阅我们的开发人员文档中的维护免除IP地址列表。
不要！：
- 启动其他营销活动，这可能会给您的网站带来其他页面查看次数。
- 运行索引器或其他cron，这可能会对CPU或磁盘造成额外压力。
- 执行任何主要管理任务(即Commerce管理员、数据导入/导出)。
- 清除缓存。
如果您在调查并解决警报原因之前执行了任何“不响应”操作，则您的网站可能会变得无响应（如果您尚未经历网站中断）。
解决方案
按照以下步骤确定原因并排除故障。
检查Adobe Commerce支持工单是否存在。 有关步骤，请参阅我们的支持知识库中的跟踪您的支持工单。 支持人员可能已收到New Relic阈值警报，创建了票证，并开始处理此问题。 如果不存在票证，请创建一个。 票证应包含以下信息：
-
联系原因：选择“已收到New Relic严重警报”。
-
警报的说明。
-
New Relic事件链接。 这包含在您的Adobe Commerce托管警报中。
-
使用New Relic APM的“事务”页识别具有性能问题的事务：
- 按升序Apdex分数对事务排序。 Apdex指用户对Web应用程序和服务的响应时间的满意度。 低Apdex分数可能表示瓶颈（响应时间较长的事务）。 通常，它与数据库、 Redis或PHP有关。 有关步骤，请参阅New Relic 查看Apdex满意度最高的事务。
- 按最高吞吐量、最慢的平均响应时间、最耗时的阈值和其他阈值对事务进行排序。 有关步骤，请参阅New Relic 查找具体性能问题。
-
如果您仍在努力识别源，请使用New Relic APM的基础架构页面来识别资源密集型服务。 有关步骤，请参阅New Relic 基础架构监视主机页面>进程选项卡。
-
如果标识了源，请通过SSH连接到环境以进一步调查。 有关步骤，请参阅我们的开发人员文档中的SSH到您的环境中以使用Adobe Commerce on cloud infrastructure。
-
如果你还在努力找出问题的根源：
- 查看最近的趋势，以确定最近的代码部署或配置更改（例如，新客户组和目录的大幅更改）中存在的问题。 建议您查看过去七天的活动，以了解代码部署或更改中的任何关联。
- 考虑检查和禁用平面目录。 有关步骤，请参阅我们的支持知识库中的性能缓慢、运行缓慢且长时间的crons。
- 如果您怀疑正在遭受DDoS攻击，请尝试阻止机器人流量。 有关步骤，请参阅我们的支持知识库中的如何阻止Adobe Commerce在Fastly级别上的云基础架构上的恶意流量。
-
如果问题看起来是暂时性的，请执行缓解步骤（如升级）或将站点置于维护模式。 有关步骤，请参阅我们的支持知识库中的如何请求临时调整大小以及开发人员文档中的安装指南>启用或禁用维护模式。 如果Upsize使站点恢复正常运营，请考虑请求永久升级(联系您的Adobe客户团队)，或尝试通过运行负载测试并优化查询或降低服务压力的代码在专用暂存中重现问题。 有关步骤，请参阅云基础架构上Adobe Commerce开发人员文档中的测试部署>负载和压力测试。