高性能服务系列【十二】终篇:等待的代价

本文讨论了影响IT服务性能的五个关键因素:锁互斥与自旋锁、系统调用的效率、条件变量与唤醒、内存分配的优化,以及内存一致性协议。作者强调了算法在性能中的作用,并提到了定制内存分配器和使用内存屏障的重要性。
摘要由CSDN通过智能技术生成

上一篇《主题匹配》入选CSDN的区块链领域内容榜,最早我看到的时候是排行榜34名,写这篇文章的时候已经落到了46名。虽然我没有觉得和区域链有什么关系,估计入选的原因是那篇文章涉及到几个算法吧。

在整个高性能服务系列中,我很少提及算法,倒不是说和算法没有关系,确切地说,性能本身是很难脱离算法的。一个原因是算法涉及的内容过于庞杂,见《算法导论》和高纳德的《计算机程序设计艺术》;另外一个原因,性能涉及到的算法并不会太多,反而是追求简单,加上系统级别的加成。

我们在总结高性能服务系列的核心关键是减少等待时间,而尽可能让CPU有效的跑满,重点提示,是有效的CPU时间。排除显而易见的网络IO、磁盘IO或者其他慢速服务,以及代码BUG导致死锁等。

我们假设一切都是正常的,没有低级错误,那么影响性能的几个因素,在之前几个篇章都提到过,这里做下总结。

一、锁互斥

这个不需要太多解释,锁互斥对性能的影响有两个:1、临界区资源只能被一个线程访问,其他线程等待导致的性能损失;2、等待线程被系统调度,切换出执行区间,再次进入可执行状态,需要重新加载内存。

为了降低锁互斥导致的等待时间,就要缩小临界区,使得进出临界区的执行时间尽可能的小。然后,再加上自旋锁,使得等待线程不需要被切换让出CPU执行时间。

或者更干脆地采用无锁数据结构,避免锁互斥,标本兼治。但无锁数据结构极为复杂,要编写一个正确的无锁数据结构,殊为不易,性价比太低。

如果从架构设计上,去减少需要被互斥共享的临界区,也是个不错的解决方案,从理论上讲是可行的。

二、系统调用

系统调用并不像锁那样容易理解,因为调用系统API简单而自然。一般不会注意到一个简单的系统调用,需要从用户空间切换到系统空间,要经过多个调用链。

我们之前提到过linux的futex调用,就是尽量将锁停留在用户空间,除非迫不得已,才会进行系统调用。windows下也有类似的API。

三,等待唤醒

有了等待,也同样有唤醒,比如条件变量,windows和Linux下都有。使用条件变量,就会涉及到互斥锁,见第一节。条件变量和信号量唤醒机制,都会出现虚假唤醒和唤醒丢失。虚假唤醒,比如惊群效应,最多损失性能,而唤醒丢失就比较严重了,不单是损失性能,甚至导致程序错误。唤醒丢失在条件变量时,还特别容易出现,需要警惕。windows下的事件,Event算是一种特殊的信号量,不单独论述。

四、内存分配

内存分配所需要的时间,也很容易被忽视。考察那些高性能软件源码,大部分都会自己定制一个内存分配器,或者引入第三方tcmalloc和jemalloc。传统的ptmalloc分配小块内存的代价比较大,远不如tcmalloc和jemalloc效果好,ptmalloc2已经做了不少优化。


内存分配之所以代价比较大,有这么几个方面。1、内存和地址空间是全局,因此在分配时,存在互斥的。2、小内存分配和释放是基本操作,调用频繁,所以对性能的影响很明显。

要自己定制一个内存分配器,代价比较大,还不如tcmalloc和jemalloc,但在一些特殊场景下,比如类似流水线的场景,就容易实现,也值得去定制一个内存分配器。

五、内存刷新

内存一致性协议导致的等待,因为是纳秒级别的,基本被忽视。只有用到原子操作,追求高性能的时候,才会被重视。题外话,用到原子操作时,必须特别注意到内存屏障。c++11引入了原子,std::memory_order集成了内存屏障,因此,需要理解每个memory_order的含义。

  • 4
    点赞
  • 7
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值