我是公司的一块砖，哪里需要往哪搬。如果研发人不足，数据也可做后端。
数据组老大离职，一堆数据接口代码等待人来接管，我天天祈求这些代码不要出问题，然后美梦就成真了，今天，其中一个提供关键词的接口慢的一批.
恰逢此时，领导在我背后拍了拍我的肩膀，有为啊，这个问题就交给你来处理了吧，你可从来没让我失望过啊！
当时，在下的心情比吃了七斤二两新鲜的热翔还要难受，鼓励我做事（晒甩事情）的话你都说，鼓励我做事（加薪）的事你不做，我给你说个锤子。
狠话虽然这样说，但是还是要恰饭的，为了这口饭，在下只好忍气吞声，卧薪藏胆，悄悄咪咪的剧情情况。
cat 8000_supervisor_runtime.log | grep keyword
看supervisor的日志，响应时间搞到100多万ms的都有，看完之后我慌得一批.
cat /var/log/nginx/access.log | grep keyword
然后去看nginx日志，几乎全是清一色的499。
百度了下nginx 499的说明，client has closed connection，客户端关闭了连接，顺带了还看了下解决方法，修改nginx配置**proxy_ignore_client_abort on;**表示代理服务端不要主要主动关闭客户端连接。
照着修改之后，依然没有任何改观，让后在下就裂开了，真的是能力有限啊，是在搞不定啊。
比对了测试环境和生产环境，测试环境响应都在1s一下，而且接口代码逻辑也相当简单，就是查询数据库，然后调用下相关模型，返回最匹配的关键词。
同样的代码，同样的逻辑，就连查询的数据库都是一样的，为什么差别会这么大，我当场就蒙了，。
&emspl;思前想后，在线感觉无非就是两个问题。
1、nginx的问题
会不会是请求数过多，nginx吃不消了，但是在下马上就否定了自己的想法，如果nginx的问题，其他的接口肯定也会出问题，但是当时的情况是各别接口慢，其他接口快的飞起，所以nginx问题排除。
2、代码的问题
最开始，我是不想承认代码的问题的，因为代码自从组长离职一个月期间，一直没有出过类似的问题，但是当时处于特殊情况，只要是其中给一个影响因素，我就不得不怀疑。既然是接口响应慢，我干脆就把接口的代码逻辑全部毙掉，如果接口响应时间变短了，那么就是代码的问题。
注释掉所有业务逻辑代码，直接返回值，接口响应时长立马从100万ms降到0.2ms，我特么当时就惊了，代码是不会骗人的，但是为什么这么简单的代码，会出这么大的问题，我就有点难懂了。
代码最核心的逻辑，是从数据库查询数据，莫非是这里除了问题，突然间在下恍然大悟，代码没问题，nginx没问题，真正有问题的其实是数据库的问题。数据库连接池被占满了
查询一下PG的连接情况，一共有180多个连接（tornado异步连接池最大的连接数是120），这180多个连接一直没有被释放，而且还有增加的趋势，所以导致了我那个接口查询数据的时候，一直被堵塞在哪里。
SELECT
query
FROM
pg_stat_activity
WHERE
STATE = 'active'
查询具体的查询语句，发现这些语句都特么慢的一批，而且语句都来源于同一个接口，经过排查，发现这些SQL是老版本的关键词推荐的代码，完全可以用新版本替代（fuck老版本兼容）修改一下代码函数调用，重启supervisor，监控一下PG的连接数，瞬间降到10以下，所有的接口全部快的飞起，这个世界一下就变得美好了。