关于 V2EX 在 2014 年 6 月初遇到的性能问题

[Livid]

大概是从 5 月中开始，页面的生成时间就越来越长，但是我一直没有找到原因。因为同样的代码，在开发环境里跑是 8ms，到了生产环境就变成 180ms，这太奇怪了。

而且这个性能问题在过去的几个星期里呈现恶化趋势。终于在 2014 年 6 月 10 号这天让网站彻底打不开了。

彻底打不开的那段时间，我看到 CPU 占用率最高的一个进程始终是 redis-server。所以这种情况下，需要的是一个能够 profiling redis 的工具，我在 GitHub 上找到了 Instagram 开源的这个工具：

https://github.com/Instagram/redis-faina

然后，在经历了之前半个月的各种难受和猜测之后，终于找到了原因：

我在代码里滥用了 KEYS 这条指令。

http://redis.io/commands/KEYS

找到问题根源之后，修复就很容易了。

所以几点总结就是：

* KEYS 的性能随着数据库尺寸的增大而越来越慢
* 在一个足够大的数据库上，连续的 KEYS 指令足以让 Redis 彻底堵住

[qloog]

怪不得早上打不开呢，原来确实是故障，以为我的网络问题呢~

[cctvsmg]

这么快，不太适应
感觉刷v2ex的一大乐趣没了

[nobita]

good job

[lm902]

[lazyphp]

难怪刚才访问 出504了。

[lm902]

好不容易才打开一个页面

[yhf]

@Livid 能否透露一下KEYS现在大约是多少量级？

[kslr]

昨晚上4点左右504了

[lovelotuslonely]

@mxi1 這是啥兔，耳朵那麼大

[soli]

请问 @Livid 能不能给点数据？比如，KEY 到多大数据量的时候开始出现明显的性能下降？

还有，具体的解决办法能透露一下么？

[Yuansir]

也被KEYS坑过

[karvinchen]

学习了

[snowhs]

我就是想问下配图想表达啥...

[slixurd]

KEY这条指令我记得还在阿里还是腾讯的笔试题上出过
让我们阅读英文的manual,然后说出用法和注意事项以及猜测实现来着

[iptux]

@snowhs 配图文件大小约3M

[Livid]

@soli 100 万左右。

这次的解决方法是，需要用到 KEYS 的地方，其实是我们目前的在线人数统计，现在这个地方已经加上了缓存，所以对 KEYS 的调用就大大减少了。

[Kabie]

。。。我说怎么之前经常打不开呢……

[PotatoBrother]

现在我这已经40ms 以内了，终于可以顺畅的逛 V2 了

[cutehalo]

Livid会卖萌 谁也挡不住 XD

[decken]

www.v2ex.com 63ms