问题发生在四月下旬。当时，我发现我负责任务处理平台。加载信息页面有点慢。在这个时期开始时，网络不好。我们的服务部署在美国AWS的EC2机器上。两天后，我发现它仍然很慢。在询问同事之后，他们也有点慢。加载列表花了十多秒或二十秒。哈哈，他们的容忍度很高。稍后要求的API接口很长，似乎在接口中存在问题
由于界面加载缓慢，我去看看数据库是否存在问题。该系统的数据库使用了AWS RDS-POSTPRESQL。接下来，我去了控制台页面，查看数据的一些监视指标。他们发现CPU和IO两种都是异常的
从图可以看出，数据库的CPU使用峰值情况。IO还读取最高的阅读IOPS，达到每秒10,000次。
根据CPU的使用，我怀疑它应该是由我们系统中的正时任务引起的。由于我负责一个任务处理平台，因此其中一个组成具有正时任务系统。该系统主要是进行服务的动态扩展。STATUS统计信息以及服务状态的同步。
由于这是问题，因此我首先从最近的Git commit中找到了相关代码的更改。找到了一段时间后，我发现没有相关的更改，所以我感到惊慌，为什么看起来像？分析。
我在AWS的官方网站上找到了一篇有关RDS CPU High分析的文章：
其中，使用pg_stat_statements来分析问题，因此我发现PG的官方文档以学习PG_STAT_STATETENTS的使用。我在这里使用的PG-11如下：http：//www.postgres.cn/docs/11/pgstatements.html
其中有详细的描述，所以我不会一个一个列出它们
以下是我对我有用的三个SQL，如下所示：
稍后，我使用Create扩展PG_STATTTTATTATTATTATENTENTS命令打开它
大约一段时间后，我进行了总时间 - 耗尽的SQL，结果如下：
当我看到第一个时，我发现这个呼叫非常高，并且总的时间消耗非常高。平均一个达到2秒。这只是一个选择的单点查询。在这个地方可能有问题，因此我使用D表来输出该表的表结构信息，如下
一看到这一点，我发现有问题。与ECS_TASK_ID相关的索引是关节索引。我们可以从图中看到，但是令人尴尬的ECS_TASK_ID位于关节索引的第二个字段上，这意味着如果您仅使用ECS_TASK_ID，则不能使用此组合索引
为了验证，我自己写了一个查询，如下所示：
从上面的执行计划中，我们可以看到SEQ扫描，也就是说，使用全表扫描，因此执行也很高，并且查询消费达到5秒；
解决问题的方法实际上是一个简短的答案，只要您在此表中添加ecs_task_id索引
优化之后：
显然，CPU和IOPS显然都得到了改善
由于问题的定位，我也知道问题的SQL，然后我去了一个问题的地方。我检查了项目中使用该项目来查询DPP_Process_Service_task表的地方。引起问题的代码：
保存此dpp_process_service_task时，存在查询和判断。如果存在，则如果不存在，它将进行更新。为什么这种逻辑？此方法用于每个POD的状态以及同步服务的扩展服务的POD数量，因此调用非常普通，并且情况较慢，因为表中的数据量在dpp_process_service_task中，我现在检查了超过500万的数量，所有查询都会导致这种时间消耗。最近，该平台的服务已逐渐从AWS的ECS和Fargate迁移到自行构建的K8S群集，因此它导致了监护服务的数量正在增加
dpp_process_service_task会生成数百万个数据，但是平台服务超过100。由于我在那里数据处理平台，因此数据服务将更多地针对扩展服务的POD，这将导致服务POD频繁。拉起并关闭，但是与K8相比，每个POD的ID绝对不同，因此它导致越来越多的历史数据
稍后我进行了优化，仅保留了将近一周的搜索和使用的POD历史记录，并在此表中解决了大量数据问题；
1：https：//developer.aliyun.com/article/52245
2：https：//aws.amazon.com/cn/premiumsupport/knowledge--rds-aurora-postgresql-high-cpu/
3：http：//www.postgres.cn/docs/11/pgstatstatements.html
原始：https：//juejin.cn/post/7102441657114558501