redis的一点小问题

redis是一个很NB的nosql,吞吐量很高,在对服务器做benchmark的时候10W qps都没有问题。

但是这样一个大杀器要是用的地方不对就问题也挺多。

然后用了 redis-faina.py 这个工具去检查到底有多慢,发现真的很慢啊,这个时候还没有怀疑是这个python脚本的问题。这个是后话了

然后用strace -rp 进行检查,发现每个get, set都非常慢,有时候居然要100ms来完成,查询了一下,这个get的结果是空啊。

看了下这个redis的qps才2啊, 一台可以支持10W qps的redis服务器怎么在2个qps的情况下会那么慢呢。赶紧检查配置。从头看到尾就发现如下这个不熟悉的配置。


# Redis calls an internal function to perform many background tasks, like 
# closing connections of clients in timeot, purging expired keys that are 
# never requested, and so forth. 
# # Not all tasks are perforemd with the same frequency, but Redis checks for 
# tasks to perform accordingly to the specified "hz" value. 
# # By default "hz" is set to 10. Raising the value will use more CPU when 
# Redis is idle, but at the same time will make Redis more responsive when 
# there are many keys expiring at the same time, and timeouts may be # handled with more precision. 
# # The range is between 1 and 500, however a value over 100 is usually not # a good idea. Most users should use the default of 10 and raise this up to 
# 100 only in environments where very low latency is required. 
hz 10 

默认这个配置都是开启的,并且为10。只看到最后一句,当在低延迟的环境中,会把这个值从10提升到100。我又做了一个测试,在50,60,70这些时候效果都不明显,但是一到了100就效果立刻就显现出来了,然后又观察了一下cpu的使用率,还行,比平时多了1%也就。这个等以后并发量上去后再调低下来也可。

再说前面那个redis-faina.py脚本的问题,看了下,原来那个所谓的执行时间都是通过两两相减得来的,不是一个肯定的数值。于是我就看了下strace的结果,发现没有问题,为了验证是否真的没有,还把slow-log的设置减少到10微妙,这个时候还是验证了strace的结果是正确的,终于所有的请求都降低到10ms以下。

真是不容易,以后还是少用点第三方的脚本分析吧,还是自己来吧。 至于hz这个参数,有能力的就参考下源码吧,这个是2.6以后新加的参数。

关于 Timo
XNIX SA & MYSQL DBA

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s

%d 博主赞过: