上下文切换的资源消耗

2020 年 05 月 12 日 阅读数: 4
上下文切换的资源消耗

当大家在设计高并发服务的时候,多线程的模型已经成为主流设计。很多人心中都有这样一个常识:线程之间的上下文切换的成本是很昂贵的,开上千个线程对内存的压力很大,那么这里我们一起来分析一下,到底,上下文切换要花多久时间,占用多少资源。

Linux线程和NPTL

在2.6版本之前,Linux对线程支持的不好,主要靠的是在进程上做一些hack来实现线程。在Futexes出现之前,既没有低延时的同步方案(当时一般使用信号来进行同步),也不能很好的利用多喝系统的能力。

在2005年,红帽的Ulrich Drepper和Ingo Molnar两位大佬提出了Native Posix Thread Library,简称NPTL,并把NPTL整合进了Linux 2.6。有了NPTL,线程的创建时耗快了7倍,通过使用futexes,同步操作也变得非常的快。内核更加重视使用多核硬件的能力,将线程和进程变得更轻量。与此同时内核还加入了一个更高效的调度器:O(1) scheduler。

上下文切换时会发生什么?

首先,在上下文切换会切换到内核态。这里会需要保存线程的寄存器,并且跳转到内核代码。切换可能是通过一个显式的系统调用,或者是时间中断,也就是内核抢占了一个用户线程进行调度。

然后,调度器开始决定接下来执行哪个线程。选定线程之后,需要把新线程的page tables加载到内存中。

最后,内核恢复新线程的寄存器,切换回用户态。

上下文切换的成本

要准确的测量两个线程进行上下文切换的开销,我们需要小心的触发切换,避免额外的工作。这样可以测量切换的直接成本。实际上上下文切换还存在间接的成本,每个线程都有一组自己占用的内存,其中一部分可能在cache中,当我们切换到其他进程的时候,这些cache数据会慢慢的被踢出。在线程之间频繁的切换会导致cache数据反复变化,降低命中率。

本文要测量的成本,只考虑直接成本。我们创建两个线程,线程间通过一个pipe发送小量的数据。读线程在进行read时会阻塞,这时操作系统切换到写线程。我们再单独记录一下写数据需要占用多久时间,将总时间减去写数据的时间,就大概得出了上下文切换消耗的时间了。在我的笔记本上,这个时间大约是1.3微秒。

上下文切换还有一个隐性的成本,在多核机器上,内核有时候会将一个线程在多个核之间迁移,原因是这个线程之前使用的核还被别的线程占用了。内核的这种操作可以更加充分的利用多核系统,但是因为核有自己的cache,这样也会一定程度上增加开销。我们可以使用taskset命令来强制程序使用一个核,这时,我们测出来上下文切换大约是0.9微秒。

1微秒这个结果说明了一个问题,在现代的linux系统中,上下文切换非常的快,比我们绝大部分的业务代码都快,所以上下文切换不应该成为性能设计时候的理论瓶颈。

线程使用的内存

使用多线程来设计系统时,除了上下文切换的开销之外,大部分人还会担心线程很多的时候,对内存的占用情况。同一个进程的多个线程会共享内存,但是每个线程还会有一些私有的空间,其中stack就是很大的一部分。

每个线程的默认栈空间是8MB,可以通过ulimit -s命令来查看。

我们可以写一个程序,来创建很多个线程,然后观察内存占用,在我的笔记本上,创建10000个线程后,通过htop命令我观察到,virtual memory使用了80G,resident memory试用了240M,这两个指标的区别在哪呢?我的笔记本内存只有8G,虚拟内存为什么能用出80G呢?

首先我们来看看Virtual memory和Resident memory分别是什么东西

当Linux程序使用malloc申请内存的时候,其实并没有真的开辟一片内存区域给程序,只是在操作系统的一个表里记录了一下。只有当程序真的开始访问内存的时候,才会使用到RAM。这时virtual memory的基础。

因此,一个进程使用的内存有两种意思,一个是它占用的虚拟内存有多大,另一个是它实际占用的RAM有多大。前者几乎没有边界,而后者的上限就是物理内存的大小(超过之后还可以用硬盘,但是会严重拖慢性能)。实际使用的物理内存,就是resident memory。

所以我们应该更关心线程任务实际使用的内存,而不是担心创建线程所带来的内存消耗

结论

在现代的操作系统中,线程上下文切换的开销很小,单纯线程本身的内存开销也不大,我们应该更多的关注自己代码的性能以及内存消耗。

用户头像

麻瓜镇

关注

还未添加个人签名 2017.12.29 加入

还未添加个人简介

评论

发布
暂无评论
上下文切换的资源消耗-InfoQ写作平台