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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

› Redis

› Redis 入门指南

› phpRedisAdmin

› Deploy Redis on Ubuntu or Debian

这是一个创建于 3829 天前的主题，其中的信息可能已经有所发展或是发生改变。

大概是从 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 彻底堵住

Redis

数据库

指令

74 条回复 • 2014-06-30 15:11:11 +08:00

twoconk

2014-06-10 11:43:25 +08:00

学习了：）

yangyang

2014-06-10 11:43:57 +08:00 via Android

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

jedyu

2014-06-10 11:44:50 +08:00

修复就好

zuroyu

2014-06-10 11:46:04 +08:00

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

KennyZJ

2014-06-10 11:47:06 +08:00

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

homever

2014-06-10 11:47:27 +08:00

back

shao

2014-06-10 11:47:54 +08:00

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

xuc

2014-06-10 11:48:00 +08:00

30ms

Livid

MOD

2014-06-10 11:48:05 +08:00

@shao 是

wwqgtxx

2014-06-10 11:48:11 +08:00 via Android

现在好快，赞一个

shao

2014-06-10 11:49:31 +08:00

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

@Livid

canesten

2014-06-10 11:49:51 +08:00

大意失荆州
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

2014-06-10 11:50:45 +08:00

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

lovelotuslonely

2014-06-10 11:54:08 +08:00

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

DearMark

2014-06-10 11:54:27 +08:00 via Android

33ms 这性能终于爆棚了

Tink

2014-06-10 11:55:14 +08:00

29MS

cj1324

2014-06-10 11:56:52 +08:00

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

mxi1

2014-06-10 12:02:39 +08:00

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

mxi1

2014-06-10 12:03:16 +08:00

@lovelotuslonely 大兔子🐰

hitigon

2014-06-10 12:06:02 +08:00

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

qloog

2014-06-10 12:07:22 +08:00

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

cctvsmg

2014-06-10 12:08:24 +08:00

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

nobita

2014-06-10 12:15:26 +08:00

good job

lm902

2014-06-10 12:15:39 +08:00

lazyphp

2014-06-10 12:15:50 +08:00

难怪刚才访问出504了。

lm902

2014-06-10 12:16:17 +08:00

好不容易才打开一个页面

yhf

2014-06-10 12:35:00 +08:00 via iPad

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

kslr

2014-06-10 12:35:54 +08:00

昨晚上4点左右504了

lovelotuslonely

2014-06-10 12:36:45 +08:00 via iPhone

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

soli

2014-06-10 12:41:09 +08:00

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

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

Yuansir

2014-06-10 12:42:37 +08:00

也被KEYS坑过

karvinchen

2014-06-10 12:50:17 +08:00

学习了

snowhs

2014-06-10 12:53:45 +08:00

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

slixurd

2014-06-10 12:55:52 +08:00

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

iptux

2014-06-10 12:57:38 +08:00

@snowhs 配图文件大小约3M

Livid

MOD

2014-06-10 13:07:28 +08:00

@soli 100 万左右。

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

Kabie

2014-06-10 13:14:13 +08:00

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

PotatoBrother

2014-06-10 13:15:48 +08:00 via iPhone

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

cutehalo

2014-06-10 13:18:22 +08:00

Livid会卖萌谁也挡不住 XD

decken

2014-06-10 13:30:36 +08:00

www.v2ex.com 63ms

soli

2014-06-10 13:35:48 +08:00

@Livid 非常感谢。我也回去找找我代码里的 KEYS 。。。

missdeer

2014-06-10 13:36:59 +08:00

75ms

Numbcoder

2014-06-10 13:41:55 +08:00

keys 相当于 select * ，在产品环境几乎是要禁用的。
还有 Instagram 那个脚本也会对性能有很大影响，在产品环境还是少用！

Los

2014-06-10 14:32:55 +08:00

@Livid 在线人数统计为什么不用 Sorted Set 呢？Sorted Set 天然适合干这事
r.zadd("v2ex:online", int(time.time()), member.id)
r.zrangebyscore("v2ex:online", int(time.time()-60*10), "+inf")

Livid

MOD

2014-06-10 14:39:00 +08:00

@Los 明白了。谢谢。

Los

2014-06-10 14:44:29 +08:00

@Livid 汗，对 Python 不熟悉，第二段代码应该对取 Unix timestamp 的函数搞错了。

yueyoum

2014-06-10 14:51:26 +08:00 via Android

这要是别人来说这个问题，估计早就被你们喷死了吧……

2014-06-10 14:57:23 +08:00

@yueyoum 应该不会吧, v2ex 气氛还是挺好的,不过 Livid 比较特殊, 自带主角光环, 所以你懂的.

Livid

MOD

2014-06-10 14:58:33 +08:00

@yueyoum
@9

我每天各种压力也很大。

Tinet

2014-06-10 15:05:39 +08:00

看来在做开发的时候还是要抽空多读读官方的文档啊

westup

2014-06-10 15:20:55 +08:00

速度好快啊现在

est

2014-06-10 15:31:14 +08:00

@Livid 可以改用SCAN

jevonszmx

2014-06-10 15:47:51 +08:00

哈，记得一定要看redis手册中的时间复杂度啊，比如ltrim、hgetall之类的，就是陷阱啊，分分钟卡死redis。

Los

2014-06-10 16:09:24 +08:00

#44
总在线人数统计使用 ZCOUNT
r.zcount("v2ex:online", int(time.time())-60*10, "+inf")
某用户是否在线使用 ZSCORE 取得最后活动时间进行判断
r.zscore("v2ex:online", member.id)

wenbinwu

2014-06-10 16:13:46 +08:00

昨天我也碰到一个django的性能问题
ModelFormSet没有指定queryset就会默认使用all()
在production直接100%cpu然后死在那了

ipconfiger

2014-06-10 16:33:26 +08:00

keys 是 O(n)级别的操作啊，绝对不能直接暴露出去调用的

ngn999

2014-06-10 16:38:03 +08:00

不适应这么快的速度。=͟͟͞͞ʕ•̫͡•ʔ

cloudzhou

2014-06-10 16:52:52 +08:00

@Livid
"这次的解决方法是，需要用到 KEYS 的地方，其实是我们目前的在线人数统计，现在这个地方已经加上了缓存，所以对 KEYS 的调用就大大减少了。"
这么看起来，你只是减少了 KEYS 的调用次数，可能就是加入缓存，每3，5分钟 keys() 一次。

我认为这样的做法还不够优雅，对你现在说的这个需求，以下是我的做法：
引入 Sorted sets，创建一个名字叫： user:online
当用户 user(id: user_id)，进行一次页面操作的时候，timestamp_now 就是当前时间戳：
> ZADD user:online timestamp_now user_id
对于每一个用户的页面操作都是做这样的操作

* 最新的用户在线列表（精确列出在线用户，以下统计前 1000 个在线用户，按照时间戳逆序）*：
> ZREVRANGE 0 1000
1) user_id_1
2) user_id_2
...

* 统计 5 分钟内的用户数（其实在线是个虚幻的概念，只能说 x 分钟内活跃认为在线）*
> ZCOUNT myzset (timestamp_5_minutes_ago timestamp_now

* 定期清除 x 分钟内没有活跃的用户，控制 Sorted sets 的长度 *
> ZREMRANGEBYSCORE myzset -inf (timestamp_10_minutes_ago

上面操作复杂度：O(log(N)+M) 这是可以控制的，并且数据非常及时和准确。

其实这是一个很好的面试题目。
广告：我需要前端工程师，设计师： http://v2ex.com/t/115602

holy_sin

2014-06-10 16:55:28 +08:00

这个兔子好大

RoCry

2014-06-10 17:01:24 +08:00 via Android

早知道有这么大的图就不点开了... 我的流量...

Mac

2014-06-10 17:18:08 +08:00

现在的速度快的像飞一样啊

keakon

2014-06-10 17:20:33 +08:00

更简单的方案是放在一个单独的 db 里。

ShunYea

2014-06-10 19:58:35 +08:00 via Android

40MS，相当不错

spoonwep

2014-06-10 22:19:53 +08:00

原来如此，最近正在倒腾redis，学习了！

sdjl

2014-06-10 22:22:38 +08:00

想知道v2ex每天pv有多少~~？

precisi0nux

2014-06-11 09:50:57 +08:00

14ms, nice!

wikimore

2014-06-11 17:01:44 +08:00

redis数据越多越觉得坑

nezhazheng

2014-06-12 09:17:45 +08:00

scan就是被设计来解决这个问题的，生产环境keys肯定得禁用，redis单线程，keys之后，其他连接全部等待。

geew

2014-06-30 10:57:26 +08:00

@cloudzhou
@Livid
@nezhazheng
@Yuansir
@KennyZJ
@est

keys = conn.keys(key + '*')
if keys:
conn.delete(*keys)

那使用keys的地方该用什么呢? 比如要删除一些缓存然后知道key的开头..如上代码. 该怎么优化呢??

Livid

MOD

2014-06-30 10:58:22 +08:00

@geew 如果 keys 这样的指令是每 10 分钟运行一次，那不会有太大问题。但是如果是每几秒就需要运行一次的话，你就需要考虑其他替代方案了。

geew

2014-06-30 11:09:44 +08:00

@Livid 目前主要用来删除某些相同前缀的缓存, 频率不是固定, 跟后台人员编辑新建数据有关, 问题我觉得倒不会有, 因为数据量不大而且更新也不频繁, 因此其实这条语句使用不多. 但看到了总觉得是个隐藏的坑, 因为这是个组件, 不排除以后会用在别的地方.
也看到了scan, 但不知道是不是我的使用方法有问题,一直报错: ResponseError: unknown command 'SCAN'

scan的原型不是这样的么
#con.scan(self, cursor=0, match=None, count=None)

这样用: con.scan(match=keys+'*')? 有问题?

cloudzhou

2014-06-30 11:21:57 +08:00

@geew
@Livid
按照我的观点，那就是根本不要在线上使用 keys 这个指令，哪怕为了未来考虑，这是定时炸弹。
按照你上面的例子，解决方法其实很简单，两种策略：

1 外部引用，举个例子来说，就是添加值的时候做一次引用：
对 namespace.xx.yy 设值，同时把这个 namespace.xx.yy 放入 sets （以 namespace 划分的 sets），当要批量引用 namespace 开头的值时，从 sets 里面遍历，然后第二次访问。
同理，删除的时候对应删除。
缺点，有时候很难保证一致性，需要做一些补偿方案，内存使用会增加。

2 版本号的概念，对于 redis，我一直还是推荐持久化数据的，并且严格控制数据的动态产生，也就是没有删除数据这个操作，但是如果你是作为 cache 使用并且数据本来就可以丢失的，那么就可以利用版本号。使用 EXPIRE ，也就是 KEY 是有一定生存周期的，并且命名是这样的： namespace.version.xx.yy 其中 version 是一个 hashes 的对应值 {namespace : version}，当你要丢弃整个版本号的时候， version = version + 1，之前的 namespace version 版本全部不再使用，在过了一段时间之后（EXPIRE）自然回收。
缺点，只使用易失性数据，cache 使用，内存使用量在丢弃频繁的时候浪费过多。

总之，根据你的需求，有很多种方法，但是尽量不要使用 keys.

nezhazheng

2014-06-30 13:46:12 +08:00

@geew

@cloudzhou
说的是对的，绝对不要在线上使用keys，scan应该是2.8之后加上的指令，你看下你的版本。

geew

2014-06-30 15:11:11 +08:00

@nezhazheng

In [2]: redis.VERSION
Out[2]: (2, 9, 1)

我的用法有问题么?