为了追求更快,CPU、内存、I/O都做了哪些努力?

商务办公
不管什么样到编程语言,什么样到代码框架,最终都是由CPU去执行完成的(当然这么说不太准确,也有GPU、TPU、协处理器等其他情况,当然这不是本文探讨的重点)。

背景

前段时间,写了一篇《高性能开发十大技术》,有读者给我私信交流,····

曾经,我面试的时候有两个最怕的。一怕问算法,二怕问高并发。

算法这个,自从关注了「小浩算法」,刷了不少LeetCode,发现还是有套路可循的,虽不敢说算法能力有多强,至少没有以前那么怕了(才怪)。

而第二个,高性能高并发技术,感觉有好多技术要学,东学一点,西学一点,不成体系。直到有一次面试,遇到了一个大牛,问到了这方面,结果被虐的体无完肤。幸运的是,这位大牛不但技术一流,还认真跟我交流了学习心得,怎么样去有体系的系统去梳理这方面的技术知识,而不是瞎学。

CPU

不管什么样到编程语言,什么样到代码框架,最终都是由CPU去执行完成的(当然这么说不太准确,也有GPU、TPU、协处理器等其他情况,当然这不是本文探讨的重点)。

所以要想提高性能,提高并发量,首要问题就是如何让CPU跑的更快?

这个问题,也是一直以来CPU厂商一直在努力追求的方向。

如何让CPU更快?CPU厂商做了两个方面的努力:

  • 加快指令执行的速度
  • 加快CPU读取数据的速度

对于第一个方向,CPU执行指令的快慢,是跟CPU的主频紧密相关的,如何更快的取指令、指令译码、执行,缩短CPU的指令周期,提升主频在相当长一段时间里都是非常有效的办法。

从几百MHz,到如今到几GHz,CPU主频有了长足的进步,相同时间里能够执行的指令数变的更多了。

对于第二个方向,如何提升CPU读取数据的速度,答案就是加缓存,利用局部性原理将内存中经常会访问的数据搬运到CPU中,这样大大提升了存取速度。

从一级缓存,到二级缓存,乃至三级缓存,CPU缓存的层级和容量也在不断提升,读写数据到时间省了不少。

但随着时间到推移,尤其进入21世纪之后,处理器厂商发现,进一步提升主频变得越来越困难了,CPU的缓存也很难进一步扩容。

怎么办呢?既然一个人干活到速度已经很难再提升,那何不多找几个人一起干?于是,多核技术来了,一个CPU里面有多个核心,众人划桨开大船,CPU到速度再一次腾飞~

甚至,让一个核在“闲暇时间”,利用“闲置资源”去执行另外的线程,诞生了让一个核“同时”执行两个线程的超线程技术。

上面简单交代了为了提升性能,CPU所做的努力。但是光是CPU快是没用的,还需要我们更好的去利用开发,否则就是对CPU算力的浪费。

上面提到了线程,是的,如何提高性能,提高并发量?使用多线程技术当然是一个非常好的思路。

但多线程的引入,就不得不提到两个跟线程有关到话题:

  • 线程同步
  • 线程阻塞

多个线程协同工作,必然会引入同步的问题,常规解决方案是加锁,加锁的线程一般会进入阻塞。

线程遇到阻塞了,就需要切换,而切换是有一定的成本开销的,不仅是系统调度的时间开销,还可能有CPU缓存失效的损失。

如果线程频频加锁,频频阻塞,那这个损失就相当可观了。为了提升性能,无锁编程技术就出现了,利用CPU提供的机制,提供更轻量的加锁方案。

同时,为了让切换后的线程仍然能够在之前的CPU核心上运行,降低缓存损失,线程的CPU亲和性绑定技术也出现了。

现代操作系统都是以时间片的形式来调度分配给多个线程使用。如果时间片还没用完就因为这样或那样的原因将执行机会拱手相让,那线程也太亏了。

于是,有人提出要充分利用CPU,别让线程阻塞,交出执行权,自己在应用层实现多个执行流的调度,这里阻塞了,就去执行那里,总之要把时间片充分用完,这就诞生了协程技术,阻塞了不要紧,我还能干别的,不要轻易发生线程切换。

内存

与CPU工作相关的第一亲密伙伴就是内存了,二者协作才能唱好一出戏。

提升内存访问的速度,同样是高性能开发话题重要组成部分!

那如何提升呢?硬件层面程序员是很难改变到,咱们只好从软件层面下功夫。

内存的管理经历了从实地址模式到分页式内存管理,如今的计算机中,CPU拿到的地址都是虚拟地址,这中间就会涉及到地址到转换,在这里就有文章可做,有两个方向可以努力:

  • 减少缺页异常
  • 使用大页技术

现代操作系统,基本上都会使用一个叫换页/交换文件的技术:内存空间有限,但进程越来越多,对内存空间的需求越来越大,用完了怎么办?于是在硬盘上划分一块区域出来,把内存中很久不用的数据转移到这块区域上来,等程序用到的时候,触发访问异常,再在异常处理函数中将其从硬盘读取进来。

可以想象,如果程序访问的内存老是不在内存中,而是被交换到了硬盘上,就会频繁触发缺页异常,那程序的性能肯定大打折扣,所以减少缺页异常也是提升性能的好办法。

从虚拟地址寻址真实的物理内存,这个过程是CPU完成的,具体来说,就是通过查表,从页表->一级页目录->二级页目录->物理内存。

页目录和页表是存在内存中的,毫无疑问,内存寻址是一个非常非常高频的事情,时时刻刻都在发生,而多次查表势必是很慢的,有鉴于此,CPU引入了一个叫TLB(Translation Look- aside buffer)的东西,使用缓存页表项的方式来减少内存查表的操作,加快寻址速度。

默认情况下,操作系统是以4KB为单位管理内存页的,对于一些需要大量内存的服务器程序(Redis、JVM、ElascticSearch等等),动辄就是几十个G,按照4KB的单位划分,那得产生多少的页表项啊!

而CPU中的TLB的大小是有限的,内存越多,页表项也就越多,TLB缓存失效的概率也就越大。所以,大页内存技术就出现了,4KB太小,就弄大点。大页内存技术的出现,减少了缺页异常的出现次数,也提高了TLB命中的概率,对于提升性能有很大的帮助。

在一些高配置的服务器上,内存数量庞大,而CPU多个核都要通过内存总线访问内存,可想而知,CPU核数上去以后,内存总线的竞争势必也会加剧。于是NUMA架构出现了,把CPU核心划分不同的分组,各自使用自己的内存访问总线,提高内存的访问速度。

I/O

CPU和内存都够快了,但这还是不够。我们的程序日常工作中,除了一些CPU密集型的程序(执行数学运算,加密解密,机器学习等等)以外,相当一部分时间都是在执行I/O,如读写硬盘文件、收发网络数据包等等。

所以,如何提升I/O的速度,是高性能开发技术领域一个重要的话题。

因为I/O会涉及到与外设(硬盘、网卡等)的交互,而这些外设又通常是非常慢(相对CPU执行速度)的,所以正常情况下,线程执行到I/O操作时难免会阻塞,这也是前面在CPU部分提到过的。

阻塞以后那就没办法干活了,为了能干活,那就开多个线程。但线程资源是很昂贵的,没办法大量使用,况且线程多了,多个线程切换调度同样是很花时间的。

那可不可以让线程执行I/O时不阻塞呢?于是,新的技术又出现了:

  • 非阻塞I/O
  • I/O多路复用
  • 异步I/O

原来的阻塞I/O是一直等,等到I/O的完成,非阻塞I/O一般是轮询,可以去干别的事,过一会儿就来问一下:好了没有?

但每个线程都去轮询也不是个事儿啊,干脆交给一个线程去专门负责吧,这就是I/O多路复用,通过select/poll的方式只用一个线程就可以处理多个I/O目标。再然后,再改进一下,用epoll,连轮询也不用了,改用内核唤醒通知的机制,同时处理的I/O目标还更多了。

异步I/O就更爽了,设置一个回调函数,自己干别的事去了,回头操作系统叫你来收数据就好了。

再说回到I/O本身,会将数据在内存和外设之间传输,如果数据量很大,让CPU去搬运数据的话,既耗时又没有技术含量,这是对CPU算力的很大浪费。

所以,为了将CPU从中解放出来,又诞生了一门技术:直接内存访问DMA,把数据的传输工作外包出去,交由DMA控制器来完成,CPU只在背后发号施令即可。

有了DMA,再也不用麻烦CPU去执行数据的搬运工作。但对于应用程序而言,想要把文件通过网络发送出去,还是要把数据在内核态空间和用户态空间来回折腾两次,这两步还得CPU出马去复制拷贝,属于一种浪费,为了解决这个问题,提升性能,又进一步产生了零拷贝技术,彻底为CPU减负。

算法架构

CPU、内存、I/O都够快了,单台计算机的性能已经很难提升了。不过,现在的服务器很少是单打独斗了,接下来就要把目光转移到算法、架构上来了。

一台服务器搞不定,那就用硬件堆出性能来,分布式集群技术和负载均衡技术就派上用场了。

这年头,哪个后端服务没有数据库?如何让数据库更快?该轮到索引技术上了,通过给数据库建立索引,提升检索速度。

但数据库这家伙的数据毕竟是存在硬盘上的,读取的时候势必会慢,要是大量的数据请求都怼上来,这谁顶得住?于是基于内存的数据库缓存Redis、Memcached应运而生,毕竟,访问内存比从数据库查询快得多。

算法架构这一块的技术实在太多了,也是从一个普通码农通往架构师的必经之路,咱们下回再聊。

总结

高性能、高并发是后端开发永恒追求的话题。

每一项技术都不是凭空出现的,一定是为了解决某个问题而提出。我们在学这些技术的时候,掌握它出现的原因,和其他技术之间的关联,在自己的大脑中建立一座技术知识层级图,一定能事半功倍。

这幅图中的绝大多数技术,我之前都有对应的趣味故事文章进行阐述,欢迎大家去翻一番~

本文转载自微信公众号「编程技术宇宙」,可以通过以下二维码关注。转载本文请联系编程技术宇宙公众号。

 

责任编辑:武晓燕 来源: 编程技术宇宙
相关推荐

2018-01-24 11:02:44

笔记本纤薄改变

2014-11-12 00:01:29

京东

2014-07-28 16:47:41

linux性能

2019-07-16 11:10:32

CIOHermes转型

2022-07-29 09:12:14

Springservlet容器

2022-07-26 07:47:47

SpringMVC

2022-08-02 07:55:28

MVCJersey

2022-07-26 07:47:09

SpringMVC

2021-01-06 08:24:38

人工智能消费领域AI

2020-12-11 11:04:07

NettyIO

2015-11-16 17:19:13

2017-03-01 12:36:15

Linux驱动技术内存

2014-08-10 14:35:23

2017-06-08 09:36:42

京东服务器

2021-08-06 22:45:09

人工智能AI

2017-09-05 08:14:09

深度学习语音合成

2019-02-24 23:45:42

5G运营商网络

2011-02-25 09:16:00

SQLSQL Server IO

2023-06-07 08:13:46

PixiJSCanvas 库

2021-01-03 10:37:50

前端开发技术
点赞
收藏

51CTO技术栈公众号