線上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的大小便可。