开发者社区> xumaojun> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

进程上下文切换 – 残酷的性能杀手(下)

简介:
+关注继续查看

几个月一直懒得没动笔写写博客,最近开始动笔写点什么,今天就趁着加班出版本,横下心决定把上次烂尾的文章给收了(上篇:http://www.cppthinker.com/linux/224/context_switch_1/)。

接上篇,我们已经通过分析内核代码看到pthread_cond_signal和pthread_cond_wait会发生CS(Context Switch),本篇我将从实际测试数据出发,来看CS究竟会对我们的应用程序产生怎样的影响。

一般我们可以通过工具vmstat, dstat, pidstat来观察CS的切换情况。

vmstat, dstat只能观察整个系统的切换情况,而pidstat可以更精确地观察某个进程的上下文切换情况。

 

这里我用了chaos库中task_service的一个测试用例来说明情况(chaos库是我写得一个高性能并发网络库,而task_service是一个提供了多线程通信的异步消息队列)https://github.com/lyjdamzwf/chaos/blob/master/chaos/task_service/task_service.h

https://github.com/lyjdamzwf/chaos/blob/master/chaos/task_service/task_service.cpp

这两个文件中,在post异步消息给task_service_t时,会根据头文件中定义的宏在编译期控制调用pthread_cond_signal还是write(fd),这是典型的生产者消费者模型

注意,通过系统调用write来通知task_service_t内部的线程会有以下几种可能:

*) pipe

*) socketpair

*) eventfd

它们都是linux中的多进程/多线程通信的常用手段

我们直接跑一下chaos/test/task_service 下的用例来分别看下不同机制的结果吧

  CS/s post cost exec cost
pthread_cond_wat/pthread_cond_signal 600k 32,235,597 us 32,235,078 us
sleep 300 3,987,928 us 3,996,383 us
pipe 500 11,928,024 us 11,928,174 us
socket_pair 4000 16,532,314 us 16,532,461 us
eventfd 200 5,136,712 us 5,303,645 us
boost::io_service 750k 26,355,836 us 26,355,708 us

好,让我们一个一个来解读

首先,使用了pthread的条件变量的chaos::task_service引起的CS非常之大,效率也是最慢,原因其实上篇已经讲述,不管是pthread_cond_wait还是pthread_cond_signal,都会发生一次CS。

使用了sleep的chaos::task_service,效率是最高的,主要原因是在于生产者每次投递时不需要系统调用进行notify,且CS也是很小的,但是这种模型在理论上没有其他 wait/notify的模型要来的好,而且CS和整体的效率还和sleep的参数有关

pipe, socket_pair 和 eventfd 都是基于 write系统调用来notify消费者,eventfd是最新内核提供的机制,几乎感受不到的CS让其效率也遥遥领先其他的通信机制

值得注意的是boost::io_service,我这里的测试系统是linux,windows上的boost::io_service实现没有测试,但其CS切换如此之高,却整体效率比chaos::task_service使用pthread 条件变量的模型来得快一些,我想应该是由于其内部的队列实现,毕竟目前chaos::task_service的队列只是简单的lock deque。

基于以上统计,我们可以看出基本是呈现CS越少,整体运行效率越高的趋势

我们可以得出一个比较浅显的结论是,CS起码会是影响我们程序性能的主要因素之一

当然,任何时候我都觉得测试数据只是眼前的测试数据,它只能告诉我们什么东西值得我们去注意,而不是什么东西一定是怎样的,至少对于后台服务,CS应该是我们常常需要去考量性能的一个因素

好了,就到这,希望对大家有帮助 :)

PS. 加班写文章思绪有些乱,前言不搭后语望包含,赶紧撤了~

 

我的个人博客地址:www.cppthinker.com

欢迎大家交流:)

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
最新最全面的Spring详解(四)——面向切面编程(下)
最新最全面的Spring详解(四)——面向切面编程(下)
9 0
【多线程:锁】卖票程序
【多线程:锁】卖票程序
19 0
烂大街的缓存穿透、缓存击穿和缓存雪崩,你真的懂了?
烂大街的缓存穿透、缓存击穿和缓存雪崩,你真的懂了?
60 0
中国程序员视角下的英文命名
不管是日本人设计的 Ruby还是巴西人设计的 Lua,各种语法采用的全都是英语。所以,想要成为一个优秀的程序员,会用英语写代码是必要的。 但不是要求研发人员都得专业英语八级,但至少确保代码用英语表达你的意图。
64 0
进程上下文切换 – 残酷的性能杀手(上)
对于服务器的优化,很多人都有自己的经验和见解,但就我观察,有两点常常会被人忽视 – 上下文切换 和 Cache Line同步 问题,人们往往都会习惯性地把视线集中在尽力减少内存拷贝,减少IO次数这样的问题上,不可否认它们一样重要,但一个高性能服务器需要更细致地去考察这些问题,这个问题我将分成两篇文章...
1097 0
利用GPU性能指标进行弹性伸缩
随着人工智能大潮的风起云涌, 视频识别,语音识别,图像识别,自然语言翻译,AI画匠等基于GPU的在线预测也在遍地开花。而弹性伸缩对于人工智能服务来说尤为重要,一方面是业务压力峰值时巨大的计算力需求;另一方面当业务空闲时,GPU的空耗成本也是大家很难承受的。
3849 0
《中国人工智能学会通讯》——11.50 基于稀疏特征选择的异质人脸图 像合成
本节书摘来自CCAI《中国人工智能学会通讯》一书中的第11章,第11.50节, 更多章节内容可以访问云栖社区“CCAI”公众号查看。
1326 0
+关注
xumaojun
乐于学习与分析
文章
问答
文章排行榜
最热
最新
相关电子书
更多
低代码开发师(初级)实战教程
立即下载
阿里巴巴DevOps 最佳实践手册
立即下载
冬季实战营第三期:MySQL数据库进阶实战
立即下载