在 Erda 的技术架构中，我们使用了 kong 作为 API 网关的技术选型。因其具备高并发低延时的特性，同时结合了 Kubernetes Ingress Controller，基于云原生的声明式配置方式，能够实现丰富的 API 策略。

但是，没有任何效果 😓。

确定了是 admin 接口的原因后，我们决定将 admin 跟业务的 kong 实例分开，希望 admin 的调用不会影响到业务的正常流量访问，期待达到 kong 的 admin 接口慢就慢吧，但是不要影响业务的访问性能。

然而，没有任何效果😫。

kong 层面的努力无果之后，我们在测试过程中同时观察到了当调用 admin 接口试，postgres 的进程也增多了很多，CPU使用率也涨了起来，也是决定将 pg 迁移到 更为专业的RDS中。

还是，没有任何效果😭。

回滚

最终我们还是回滚到了 0.14 版本，追求暂时“心灵的宁静”。

至此，线上的尝试基本搞一段落，也大致摸清了问题复现的条件，于是我们决定在线下构造一个环境来继续找出问题的原因。

我们将有问题的集群中的 postgre 的数据备份之后然后在一个新的集群中导入:

psql -h 127.0.0.1 -U kong < kong.sql

并且开启 kong 的 prometheus 插件， 方便使用 grafana 来查看性能图标:

curl -X POST http://10.97.4.116:8001/plugins --data "name=prometheus"

curl http://10.97.4.116:8001

curl -i -X POST http://10.97.4.116:8001/services/ -d 'name=baidu2'  -d 'url=http://www.baidu.com'

curl -i -X POST http://10.97.4.116:8001/services/baidu2/routes \
-d "name=test2" \
     -d "paths[1]=/baidu2"

#!/bin/bash

curl -i -X POST http://10.97.4.116:8001/services/ -d 'name=baidu'  -d 'url=http://www.baidu.com'

curl -i -X POST http://10.97.4.116:8001/services/baidu/routes \
     -d "name=test" \
     -d "paths[1]=/baidu" 

curl -s http://10.97.4.116:8001/services

curl -i -X DELETE      http://10.97.4.116:8001/services/baidu/routes/test

for i in `seq 1 100`; do sh 1.sh ; done

curl  http://10.97.4.116:8000/baidu2

• kong 实例的 cpu 跟 mem 都持续上涨，且当 admin 接口调用结束后此现象依然没有结束。mem 上涨到一定程度会到时 nginx worker 进程 oom 掉，然后重启，这个也许是访问慢的原因；

• 我们设置了 KONG_NGINX_WORKER_PROCESSES 为 4，并且为 pod 的内存为 4G 的时候，pod 的整体内存会稳定在 2.3G， 但是  调用 admin 接口试，pod 的内存就会一直上涨至超过 4G，触发 worker 的 OOM，于是我将 pod 的内存调整到了 8G。再次调用 admin 接口，发现 pod 的内存依然一直上涨，只是上涨到了 4.11 G 就结束了，这似乎意味着我们是要设置 pod  的内存为 KONG_NGINX_WORKER_PROCESSES 两倍，这个问题就解决了（但是还有个重要的问题是为什么调用一次 admin 接口，会导致内存涨了那么多）；

• 另外，当我持续调用 admin 接口的时候， 最终的内存会持续增长并且稳定到 6.9G。

这个时候我们将问题抽象一下：

继续调查内存是被什么占用了：

• 该问题跟 kong 的升级（0.14  -->  2.2.0） 没有关系，直接使用 2.2.0 版本也会有这个问题；
• kong 每隔 worker_state_update_frequency 时间后会在内存中重建 router，一旦开始重建就会导致 内存上涨，看了下代码问题出在了 Router.new 的方法这里，会申请 lrucache 但是使用后没有 flush_all，根据最新的 2.8.1 版本的 lrucache 进行了释放问题依然存在；
• 也就是 kong 的 Router.new 方法里的其他逻辑到时的内存上涨；

• 这也就表明这个问题是 kong 存在的一个性能 bug，及时在最新的版本中依然存在，当 route 跟 service 达到某个量级的时候会出现调用 admin 接口，导致 kong 的 worker 内存迅速上涨，使得 oom 进而引发业务访问性能变差的现象，临时的解决办法可以是减少 NGINX_WORKER_PROCESSES 的数量并且增加 kong pod 的内存量，保证调用 admin 接口后需要的内存足够使用不触发 oom，才能保证业务的正常使用。