Chinaunix首页 | 论坛 | 博客
  • 博客访问: 422827
  • 博文数量: 23
  • 博客积分: 0
  • 博客等级: 民兵
  • 技术积分: 233
  • 用 户 组: 普通用户
  • 注册时间: 2017-11-28 16:33
文章分类

全部博文(23)

文章存档

2020年(3)

2019年(9)

2018年(10)

2017年(1)

我的朋友

分类: 高性能计算

2020-07-28 18:29:40

对于大部分应用来说,想要高性能,主要是要做到尽可能的减少网络请求(DBRedisMongoDBMQ)等。几乎所有的应用,性能瓶颈永远是在带宽那里;关于各个组件到CPU的时间周期,文字描述如下:L1>L2>memory>disk>internet

大家都知道IP是逐跳协议,也就是说我只能从一个路由器,到下一个路由器,再到下一个路由器,如果你的电脑到服务器,中途要经过很多个路由器,那时间周期就会长很多很多很多。为什么要做CDNP2P等也是这个考虑,缩短网络的路径(降低带宽承载也是一方面)。

就像是我有一个游戏服务器,在线人数约4000,里面是一个状态机在跑,需要不断的去检测各种状态、经验、星座、任务开放、技能开放等。一个玩家大约10个状态的判定,4000个玩家必须在200ms之内检测完毕,不然延迟会很严重,那1s就是大约执行5次,如果每一次数据都去Redis去取,大约是5*10*4000 = 200k次,别说Redis,再牛的服务器都顶不住!

遇到这种情况,建议把数据放在内存里面,直接从内存取,然后foreach。大部分的应用优化到这里,基本上应付所谓的日pv百万,就不是什么问题了。     

到了这一步,那么问题来了,对于内部应用,比如分布式文件存储、数据分析、任务调度,咋整?

对于大数据,其实一直是一个伪命题,数据量太大属于硬伤。所有的做大数据处理的,都是把数据分成小数据,然后分块来处理,最后再合并。其实从MySQLOraclemsSQL等一系列人RMDB的分区,分库上的处理就可以看出来。想要提高性能,必须要做到,每个模块处理的数据量,都是细分到了一定粒度的。这个时候indexgrouphash等的重要性,在这里就体现出来了。

若我有一个业务系统,每天的日志大约是10G,一个月就大约是300G,一季度大约1T,我需要看每小时/每天/每周/每月/每季度的各种报表,每次都去数T里面去找,肯定是不可能的。

一般按业务分析每分钟的数据,10G/24/60大约7M,然后生成一个分析后的结果文件,大约几K1小时就是60个文件,需要查看每小时的数据,则将60个文件的结果合并。

那我需要查看某一个用户,最近10天来的所有操作/订单,那原分组方式,已经无法满足,这个时候怎么办呢?

在插入用户数据的时候,可以按照一定规则,比如用户编号的后两位取摸,去存储在某一个文件里面,10G的数据,则可以相对平均的分配到100个文件里面去,需要查看某用户时,则可以针对用户编号取摸,直接定位到那个文件,然后再去里面查询数据。这个是比较简单的gourp+index。这一块想明白以后,你就可以在这个基础上面,写个定制化的简单的fs

经常听到有人说,多线程的程序还不如单线程的程序性能高。那如何编写一个能合理利用CPU资源的多线程程序?

大家都知道,线程切换是需要额外的开销,所以在编写多线程程序的时候,就需要尽可能的避免共享式资源,这样就可以在保证数据一致性的同时,而又避开线程等待的时间。

举个简单的例子:

我有个大的字典(Dictionary/Map)存放用户的会话数据,每个线程,去这个字典里面去读/写数据的时候,都需要去上锁,才能保证数据的一致性,如果两个(更多)线程同时去读/写数据,其他的线程就需要去等待当前线程释放资源,线程越多,则等待的几率越大,性能则越差,多线程处理变成了单线程处理,且等待完了以后,能否再切换回来这个线程继续执行,又是另外一个开销,这一部分属于系统拖托管,属于不可控的。

那么问题来了:怎么解决呢?

根据硬件和实际测试数据,合理分配线程资源,比如,我初始化了8个线程,每个用户的请求,对于线程总数取模,保证每个用户的请求,同一个线程处理,则可以在每个线程内部,存放这些用户数据,每个线程在自己内部进行存取,避开了lock,也避开了线程等待/切换带来的资源开销。不取模,随机分配线程,然后用一个hash表来存放,也可。让每个线程,专注于做自己的事情,任务调度作业,也是基于这个处理。把线程处理机制,放大到虚拟机/物理机之间的消息分发,也是如此。

总体来说,避开网络开销,避开海量数据,避开资源争夺 是所有高性能的几个基本要素。

 

阅读(4707) | 评论(0) | 转发(0) |
0

上一篇:近况

下一篇:天道

给主人留下些什么吧!~~