关于 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 彻底堵住

[twoconk]

学习了：）

[yangyang]

現在頁面生成很快，這個頁面只要 33ms。Good job！

[jedyu]

修复就好

[zuroyu]

是的，我们已经禁止使用keys操作了，每次的keys都会带来许多超时...

[KennyZJ]

原来因为这个。
我记得很早想用keys做模糊查询的时候就因为看到了作者这条警告只好作罢，一直没做过测试。
感谢分享这次经验。
新的v2.8.9里面的zrangebylex倒是可以值得考虑发挥一下作用。

[homever]

back

[shao]

请问，这个配图是为了卖萌嘛？

[xuc]

30ms

[Livid]

@shao 是

[wwqgtxx]

现在好快，赞一个

[shao]

http://www.v2ex.com/static/js/jquery.min.map 404

@Livid

[canesten]

大意失荆州
Reids官方自己在指令列表里清楚的写明了Warning

Warning: consider KEYS as a command that should only be used in production environments with extreme care. It may ruin performance when it is executed against large databases. This command is intended for debugging and special operations, such as changing your keyspace layout. Don't use KEYS in your regular application code. If you're looking for a way to find keys in a subset of your keyspace, consider using sets.

http://redis.io/commands/keys

[tonghuashuai]

记得当初开始学 redis 的时候，说完 keys * 就提到了在生产环境慎用 keys，没想到 @Livid 给亲身示范了下……

[lovelotuslonely]

跟著警長的那隻是甚麼。。。（我好弱）

[DearMark]

33ms 这性能终于爆棚了

[Tink]

29MS

[cj1324]

memcached不提供类似keys命令。 看来也是有益处的。

[mxi1]

这张图竟然有3m大，怪不得一直卡啊卡啊，还以为gif图就这样呢～～～～

[mxi1]

@lovelotuslonely 大兔子🐰

[hitigon]

Livid卖萌都卖得这么正经……（倒地