线上redis服务内存异常分析。
項目中,新增了一個統計功能,用來統計不同手機型號的每天訪問pv,看了下redis2.6有個setbit的功能,于是打算嘗嘗鮮把
redis從2.4更新到了2.6
因為是租了vps。服務器的內存只有4g可以用,最近發現系統 負載很大。發現是redis服務引起的。
查了下redis的key db1 6w+。db1 不到2k。內存監控確有4.5g(這個很奇怪)。
?
這是很不正常的。想了最近在db1加了很多bit。于是把db1 flushdb。
發現內存占用一下就刷刷的降下來了。
查了不少關于reids bit的資料。剛開始還堅信可能是redis的一個bug。昨天晚上找了凌晨2點多。還是沒啥頭緒。很惱火。
今天仔細看了下redis的 setbit 命令。恍然大悟。我做了件多么傻b的事情。
setbit 命令
SETBIT key offset value
參數 offset? 的說明
offset 參數必須大于或等于 0 ,小于 2^32 (bit 映射被限制在 512 MB 之內)。
對使用大的 offset 的 SETBIT 操作來說,內存分配可能造成 Redis 服務器被阻塞。具體參考 SETRANGE 命令,warning(警告)部分。
?
然后在程序中查看我的offset設置。
因為是需要統計某個機型每天的pv。所有為了最大限度防止誤差,offset 格式是當前時間的HHmmssss
SimpleDateFormat msdf = new SimpleDateFormat("HHmmssss"); long offset = Long.valueOf(msdf.format(new Date()));//時分秒毫秒 redisClient.setBit(hkey,offset,true);算了下offset的最大值是23595999 最小值是0,平均值是11798000,也就是說。在二進制數據上在11798000位上置1
??? 然后又算了下
??? 11798000/8/1024/1024=1.4M
因為 db1 全是bit結構,差不多2k的樣子。這樣一共占用了1.4*2k=2.8g內存。
這就找出問題所在了。修改offset的大小即可。
?
?
?
?
?
?
?
?
?
轉載于:https://www.cnblogs.com/montya/p/3162114.html
總結
以上是生活随笔為你收集整理的线上redis服务内存异常分析。的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 数学笔记--初等数学
- 下一篇: ibernate ID生成策略 小知识