进程上下文切换 – 残酷的性能杀手（下）

几个月一直懒得没动笔写写博客，最近开始动笔写点什么，今天就趁着加班出版本，横下心决定把上次烂尾的文章给收了（上篇：https://blog.csdn.net/zhangmingcai/article/details/84823156）。

接上篇，我们已经通过分析内核代码看到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应该是我们常常需要去考量性能的一个因素

好了，就到这，希望对大家有帮助

本文转自https://www.cnblogs.com/xumaojun/p/8531951.html