Redis各种数据结构性能数据对比和性能优化实践

  很对不起大家,又是一篇乱序的文章,但是满满的干货,来源于实践,相信大家会有所收获。里面穿插一些感悟和生活故事,可以忽略不看。不过听大家普遍的反馈说这是其中最喜欢看的部分,好吧,就当学习之后轻松一下。

Redis各种数据结构性能数据对比

测试工具:perf4j

性能指标:平均值,最小值,最大值,方差

对比将814条数据按单条插入到哈希MAP和哈希SET:

 对比从814条数据的哈希MAP和哈希SET中判断一个元素是否存在(map的hasKey和set的isMember):

大量数据插入哈希MAP,运行一个多小时插入到2w多条的时候再也插入不进去了。想单个删除也很慢,跟插入差不多的慢。但是删除一整个key却很快。这和C语言的原理有关。删除key其实是删除的对value的引用,内存空间不需要重置,只在需要的时候将其重写。写过一个C语言基础入门的程序:

#include<stdio.h>
main(){
    int a[5]={1,2,3,4,5};
    int b[5]={1,2,3};
    int c[]={1,2,3,4,5};
    static int d[5];
    int e[5];
    int f[0];
    int i;
    for(i=0;i<5;i++)printf("%10d",a[i]);printf("\n");
    for(i=0;i<5;i++)printf("%10d",b[i]);printf("\n");
    for(i=0;i<5;i++)printf("%10d",c[i]);printf("\n");
    for(i=0;i<5;i++)printf("%10d",d[i]);printf("\n");
    for(i=0;i<5;i++)printf("%10d",e[i]);printf("\n");
    for(i=0;i<5;i++)printf("%10d",f[i]);printf("\n");
}

运行结果:

最后两行出现这个结果的原因是分配的地址空间原来是什么值就会显示什么值,所以是随机的。

 性能优化实践

  前段时间我改了并发量最大的媒资接口的JVM启动参数,修改之前栈空间是4G,新生代是1G,基本没有full gc。minor gc相当频繁,平时1秒1次,并发量上去之后每秒4,5次。我将栈空间设置为8G,新生代设置为5G,平时大概4,5秒一次,估计并发量上去之后还是会达到1秒1次。当然有的机器会少些。因为我们公司用的是SLB的7层负载均衡,采取的是轮询策略,负载不是很均匀。我现在在试图从根本上解决问题,找到minor gc频繁的原因,最终要将minor gc口平时控制在12秒一次以上。12秒这个数据是怎么来的呢。

看我标出来的这两个差值,大体新生代的垃圾回收时间是18ms。如果12m一次,就是12000ms中垃圾回收时间占18m,千分之1.5的时间用于垃圾回收,这个比率对于整体性能的影响就没那么大了。当然各个数组会随调整变化,到时候要看情况。

  之前我也参与过这个媒资接口的性能优化,一直没有成效是因为第一我对媒资接口不熟,我也不是最主要的负责人,很多事情做不了主。其实,一般解决这个问题的方式是横向扩展,其实我们有很多空余设备,德伟不肯试试,我也没办法。另外,媒资接口虽然是我们这边最重要的接口了,但是我总会被临时调到一些更紧急的项目中去,东一点西一点的。虽说觉得自己是个SMP(对称多核处理器),但是内核上下文切换也得保存现场吧,开销很大,做不深入,时间片又到了。这都是自己当初没有想好,没有自己的负责区域,所以会被来回调。所以现在就做两件事情。如今设备复用先不考虑了,先从根本上改善程序。

我做了一晚上的测试,凌晨4点才睡。得出来一个结论:我们的定时加载本地缓存对性能有影响。第二天我在地铁上就发消息到群里说找到性能上不去的根了。第二天我们开会讨论了,大家最后的决定是我的想法可以试一试。但是从统计图表上看,内存,CPU,499和响应时间关联不大。我说我们系统目前的现状也不会是一个原因造成的,定时加载本地缓存确实和内存定期的峰值很匹配,确实是问题。既然是问题,就要一点点解决。先抛开问题不谈,发现自己的另一个问题:话说的太直,太满。

  之前发生了一件事,我好好反省了一下,很多方面。

  有次照例中午和部门里一个小姑娘吃饭。她让我给她提提建议,怎样能去阿里。她说你看我人还挺可爱的,能不能靠点别的去阿里。我人实在是太直了,我就向她阐述了确实如果实力不够是去不了的。越聊到最后发现她并不是在问我的意见,只是想让我带她去阿里。我发现这个还是按照自己的思路说下去。结果人家小姑娘气的一下午没搭理我。确实我话说的太直太满,是我要解决的问题。也确实我认为只有实力到了才能去也只是我的想法,人家有人家的方法,只是我不知道,而且不愿意用而已。我总认为达到一个目标过程更重要,其实哪是人人都这么想的。思维不够开放。我经常给别的公司推荐人才,如果觉得这个人实力不够,我都不会给推。这倒没有错,但是对别人应该有更多的鼓励,遇到委婉的人说话要更委婉一点。

  这个小姑娘聊天中提到你看我虽然有些问题自己解决不了,但是我可以找别人解决啊,最终问题都解决了。她是觉得自己是可以干活的,那么去阿里是没问题的。其实据我了解,阿里不招这种要不要无所谓的。虽然我也没进阿里,我是这么想的。这个小姑娘虽然没去阿里,但是去的公司也都可以。但把这个归因于自己很可爱,很招人喜欢我有点不赞同。物有本末,事有始终。反思一下我自己,记得11年,换工作形式一片大好的时候,我虽然没有换工作,确实出去面过试。面试其实问题回答的都不是很好,但是都给了offer。其中面了华为的,面试官说咱俩一个学校的,咱们东大的人基础不应该这么差啊。结果什么都不会,还是要我了。究其原因,要我是因为学校比较好,然后去的公司都比较好,人不笨,觉得还是有培养价值的,反正成本也不是很高。和可不可爱关系不是很大,额,我说话是不是又太直了。其实我当初如果遇到了更多的挫折,现在技术能力应该好不少。所以现在我很珍惜遇到的问题,时间许可的范围内,解决不好过程,不去追求结果。特别是做技术的,长远稳定性,前瞻性,很重要。还有一点,女孩子其实在技术工作中面对的劣势远远大于优势,我自然也遇到过,但是我自己不太清楚是哪些。因为这个劣势体现在根本不会给我面试的机会。能让我面试的,我相信面试的过程还是很公平公正的。至少我经历过的过与不过都有理有据。

   我声称自己是个技术吃货,也就是这半年的事情。之前,一直是个技术二货。上家公司在五道口清华科技园,是朋友在那边,把我挖过去的。去的时候我就很明确的说因为这边不是很忙,我家孩子小,我要先照顾好家。分清当前事情的主次是必要的。可是记得那时候每天11点就去吃饭了,吃完饭还要去买个肯德基套餐带着去旁边清华大学,到下午3点再回去上班。很多该做的没做,该学的没学。当初的时间利用起来,现在不至于这么时不时不由自主的来一句:I am so stupid. 发现身边很多做技术的女孩子,包括自己在内,对技术现状,对各大公司的形势,各个方面摄取的信息太少。不知者无畏,反而会比较自大。前段时间自己也是很浮躁,其实技术基础都不是很扎实。我有个学弟,工作三年的时候就出去创业做CTO了。旁边也有很多人很年轻有为的,很早就不做技术了,直接转管理。我原来在想:我和他们走的路都不一样。我要尽量更多的时间活跃在底层一线,因为想要工作到60岁。提升的过早,以后会越早达到瓶颈。想法很符合自身的情况,但是实际上努力不够。行远自迩,登高自卑。时刻保持危机感,强化学习意识。

    回到最初的问题。定时加载本地缓存。我试过,对这个服务来说,已加载在本地缓存的数据获取速度比远程(其实这里测试集中缓存和数据库速度差不多)快几十倍,而且很稳定。但是最初加载的时候,我们设定启动后50秒暴露服务,也还是不能保证加载完,会导致服务重启发生短暂的连接池溢出。而且我感觉我们的dubbo连接池设置了700,太大了,反而导致响应慢。开会讨论将缓存全量更新时间由本来的一小时或者半小时设置为12小时试试结果。结果由于发生了一些非技术原因现在正式环境还没有试,测试环境没有对比。但是开头介绍的redis缓存完全可以派上用场。在key值1000个以下的小本地缓存可以第一次加载的时候从redis缓存里取,redis缓存由单独的后台服务控制更新,记录最后更新时间。其实更新服务我放到离线服务里了。如果最后更新时间发生变化才会再次取最新数据。我观察了一个星期,字典值,TV值,字典配置值一个星期就没变过。耗费那么大的性能去更新,好心疼。然后20几万占100M多栈内存的明星数据,定时全量和增量执行更新,启动都需要几十秒做这个事情,当初写这个代码的哥哥,你写的时候真的测试过这么做可以提高性能吗[汗]

epiphany框架改进

  既然我要写文,就不得不提一下我的开源框架进展。这是一个离线数据推送的框架,支持全量,增量和手动发送。几个部分可分开和整合部署。用户可以灵活的选取全部部署,或者部分部署。或者在需要的情况下进行升级,降级处理。目前最新版本的改进是支持全量模式耗时长的数据优先运行的策略,以达到总体数据各个线程间耗时平均。当然用户可以自己决定是否使用此策略。在全量增量同时运行的情况下,支持both模式和yield模式。both模式即运行全量的情况下也运行增量,yield模式即全量运行时增量暂停,待全量运行完接暂停时间点继续运行。详情请参阅我的github代码:https://github.com/xiexiaojing/epiphany

   我在写框架的时候,必定用到很多测试和性能监控的东西。其中JVM我打开了很多参数,发出来供大家参考,红框标出的是一些监控,测试时可以打开。

  程序在跑,今晚够呛能睡觉。

生活点滴

  前段时间坐公交车,上来一个2岁左右的小朋友,上车一会儿后开始哭,声音特别大。我犹豫了一下,翻翻包,找到之前包上掉下的一个装饰,因为还挺好看的,我顺手就装包里了。我拿到小朋友的面前,让他猜猜这个饰品的两面是不是一样的。他不哭了,也不回答,愣愣的看着我。我就把饰品递到他手上,回到自己的位子。小朋友没有再哭。下车之后,小朋友在车窗那边跟我打了好几个飞吻,这招我儿子就不会。当初犹豫了一会儿是在想万一哄了还哭,一车人看着我多尴尬。但是想想别把自己当回事,大家谁有闲心看我。事实证明我错了,我看到全车人都在看我。但是想做什么就去做吧,做了就不后悔了。

男神说我长的难看

  全世界我就认识一个当面说我长的难看的,就是我家男神。觉得我应该跟他离婚。不过想想就他嫌我难看,我当初还非要嫁他,看来我俩眼神儿都不咋地,不是一家人不进一家门,还是将就过吧。

  看看人家都怎么评价我的:

再看我家男神:

 我和男神这几年来就吵过一次架,就是他说我长的难看。我生气了,他看我生气他也生气了。摔了好几瓶红酒然后摔出门去回北京了。两个小时后他打电话回来说快到公司出差给租的房子那里了,让我别被玻璃碎片扎到。又过半小时打电话回来说已经开始往回返了。好吧,第二天他又2个多小时回到租的房子附近上班。然后我上班中午吃饭时跟女同事说我家男神说我长的难看。女同事是这么安慰我的:你就跟他说我长的好看还跟你啊,你长的好看啊。我在想在别的情况下我是不是该跟我女同事翻脸,竟敢说我家男神不好看。但是人家是好心,我也就只能低头喝粥。粥好凉好凉,心拔拔凉。

一家人相处

  我们家相处大家很自由。比如说我要是这段时间注重打扮,男神就会向我指出我哪里穿的不好看。如果我这段时间头也不梳,那就这样吧,也没人管,也没人说。我对我家男神也是,他喜欢干什么工作就什么工作,他说他想早退休我觉得也很正常。我也就默默的想想怎么解决他退休金不够花的问题。我和婆婆关系相处的特别好。首先一点,我婆婆家楼房是我们有孩子了,但是自己还没买房子的时候先给他们买的。我家嫁女儿没要人家一分钱还倒赔了嫁妆。我家两套房子首付是我出的,贷款我还更多的那套。我也不傻,之所以这么做,老人都穷过,比较看重物质。所以我付出这么多,我心里是平衡的,老人也不会对儿媳太挑剔了。然后婆婆做饭我也从来不挑,好吃就多吃点不好吃就少吃点。孩子大了,婆婆平时没事儿喜欢捡瓶子卖钱,我也没意见,各人有各人的想法,开心就好。但是我自己喝的矿泉水瓶子都会拿回家。这是一种尊重。然后婆婆留长发,她用的扎头绳总是松,所以我要是出门,必然给婆婆买个素色头绳。谢天谢地,现在的东西都是看着好看不耐用,否则我就少了一个表现的机会。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏程序人生

浪费内存?多大个事?

遥想盖子当年,MS 红火了,谈笑间,640k 内存足矣。 - 程序君 现在已经不是从指缝中扣内存的时代了。bit 在主流的解释型语言中要么失了踪迹,要么被作为...

2798
来自专栏Java Edge

epoll和selectepoll和select

3279
来自专栏FreeBuf

物联网安全研究之二:IoT系统攻击面定义分析

在前文中,我们了解了IoT技术的基本架构,本文我将来说说IoT安全,在此过程中,我们会尝试定义一种新方法来理解IoT安全,同时也会创建一个结构化流程来方便认知I...

2649
来自专栏大数据和云计算技术

大数据和云计算技术周报(第50期):NoSQL特辑

本期有 Redis、分布式、HBase、impala与hive、protobuf、Phoenix。 希望大家会喜欢!欢迎喜欢的同学打赏、转发支持社区!

713
来自专栏高性能服务器开发

10 十万在线的WebGame的数据库设计思路

在线人数预估: 在项目设计之前,需要先对运营后的服务器人数做一下预估,预计激活人数300w,活跃人数40w,同时在线10w。而服务器的设计极限则在激活人数50...

1041
来自专栏牛客网

三七互娱秋招提前批 java服务端

    我是在6月5号参加了三七互娱的秋招的web后端线上笔试,第二天又参加了java服务端的线上笔试,之后去三七大楼参加open day,然后面试时一面,二面...

891
来自专栏斑斓

可视化与领域驱动设计

从DDD的角度,领域逻辑的分析可以运用战略方法Bounded Context。可是,一个问题是:如何获得Bounded Context ? 我查看了许多关于Bo...

3489
来自专栏数据和云

时移世易:遵从既往经验致 1.5PB 数据删除,Google SRE是如何应对的?

本文出自《SRE:Google运维解密》,由Google资深SRE 孙宇聪 担任译者,首次深度剖析Google SRE。 Google Music——2012 ...

32912
来自专栏黑白安全

四月补丁增强了 AMD CPU 抵御幽灵漏洞的能力

四月的第二个星期二,微软通过自家 Windows Update 更新通道,为 AMD CPU 带来了增强的 Spectre(幽灵)漏洞防御能力。这一轮的系统级修...

683
来自专栏ChaMd5安全团队

世界智能驾驶挑战赛信息安全组——新人扫盲

0x00前言 感谢天津市人民政府与国家发展和改革委员会、科学技术部、工业和信息化部、国家互联网信息办公室、中国科学院、中国工程院、中国汽车技术研究中心、XCT...

2899

扫码关注云+社区