我们被一个 kong 的性能 bug 折腾了一个通宵

故事背景

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

在我们最早交付的集群中，kong 还是较为早期的 0.14 版本，随着业务层面对安全的要求日益趋增，我们需要基于 kong 实现安全插件，帮助系统能够具备更好的安全能力。由于较为早期的 0.14 版本不能使用 go-pluginserver 来扩展 kong 的插件机制，我们不得不在古老的集群中将 kong 升级为相对较新的 2.2.0 版本。

升级过程就不在此赘述了，基本就是照着官方文档一步步顺利的升级上去，但是在升级上去之后的几天里，我们的 SRE 团队收到了非常密集的咨询甚至是声讨，部署在该集群上的业务间歇性的无法访问，延迟非常高。

一系列失败的尝试

参数调优

最开始为了快速修复这个问题，我们对 kong 的 NGINX_WORKER_PROCESSES、MEM_CACHE_SIZE、 DB_UPDATE_FREQUENCY、WORKER_STATE_UPDATE_FREQUENCY 参数以及 postgres 的 work_mem、 share_buffers 都进行了适当的调优。

但是，没有任何效果 😓。

清理数据

由于这个集群的历史原因，会频繁的注册或者删除 api 数据，因