对于Windows而言,大部分系统资源(例如,进程数、线程数)不像Linux一样有固定的上限,而是受限于各类系统核心资源的使用,例如物理内存(physical memory), 虚拟内存(virutal memory),页面缓冲池(paged pool), 非页面缓冲池(non paged pool) 等。
在一个Windows机器上,创建进程或者线程的上限受限于上述核心资源的情况,对于不同内存大小,不同操作系统(32位,64位)而言,其创建的上限也不同。
微软专家 Mark Russinovich (Windows Internals作者) 在微软官方Blog的上文章Pushing the Limits of Windows: Processes and Threads介绍了Windows 操作系统支持的最大进程数和线程数。
根据该文章,我们总结了如下要点,请参考:
进程是操作系统结构的基础,Windows进程是一个具有一定独立功能的可执行文件关于某个数据集合的一次运行活动。在WIndows内核中有对应的进程对象(Object), 操作系统使用该内核进程对象及其关联的数据结构来存储和跟踪该可执行程序的运行情况。
线程是进程中的一个实体,是被系统独立调度和分派的基本单位,线程自己不拥有系统资源,它可与同属一个进程的其它线程共享进程所拥有的全部资源。在Windows内核中有对应的线程Object来跟踪线程的运行情况。
简单的说,线程创建的上限主要与线程用户态Stack大小,进程用户态虚拟内存大小,Kernel Stack分配大小,系统Resident available memory大小有关。
Windows进程创建时,会分配虚拟内存空间,一般而言,32位操作系统为4G(2G用户空间+2G内核空间),而64位操作系统,虚拟内存寻址则大的多(8 TB用户空间+8TB内核空间)。WIndows线程创建时,会分配用户态Stack(栈)来传递函数参数(function parameters), 管理本地变量(local variables), 保存函数返回地址(function return addresses). 一般而言,线程用户态的stack默认保留大小为1 MB。
系统Resident available memory是可以用来分配给代码和数据的物理内存。对于线程而言,其用户态Stack的作用上面已经介绍,而内核态Stack是内核中用来处理系统调用等使用,其属于系统Resident available memory,进程创建时线程的内核kernel stack的大小在32位Windows上为12K,在64位Windows上为24K.
理论上来说,一个进程所创建的线程数量为 min(进程用户态虚拟内存大小/线程用户态分配stack大小,系统Resident avaiable memory/线程内核默认kernel stack大小)。
在不同的操作系统版本(32位,64位)以及不同类型的进程(32位,64位),最高创建的线程数量是不同的。
在进程创建时,除了默认包含的线程的资源外,系统还需要预留最小的working set(工作集,归属于物理内存)满足进程基本需要,默认大小为200K。此外,进程还需要使用虚拟地址空间来存放初始化数据,包含数据结构、PTE,Handle,Objects等资源,在微软Blog的测试中,创建一个测试进程,基本上消耗1MB Commited virutal Space (已提交虚拟内存), 所以进程创建的上限受限于系统的Commit Limit(虚拟内存上限)。例如,下图是打开Windows 7的进程管理器中的资源界面,可以看到Committd virtual space 为1360MB, 而系统的Commit Limit上限为3583MB.
进程/线程的创建上限与操作系统的核心资源有着密切的联系,我们可以通过适当的调整来系统资源增加其上限。但是根据微软官方建议,如果一个/多个应用程序从设计上需要创建大量的进程/线程,而这又成为资源瓶颈,那么设计者需要重新考虑架构。
一般而言,一个可扩展的应用程序应该让正在运行的线程正好与CPU核数相同(如果使用NUMA非一致性内存访问,则与Node上CPU的数量相同),或者使用另外一种方法,将同步IO机制修改为异步IO机制,通过IO完成机制来实现CPU与线程数的对应。
本文仅供用户使用 ECS Windows 时参考,文中引用的微软官方链接,版权归属微软。请注意文章适用的操作系统范围,以及微软 Windows 产品迭代或者文档未及时更新可能带来的问题,阿里云官方不对引用的微软官方链接内容负责。
如果您对文档内容有疑问或认为文档内容有误,请及时通过文档下方的评价板块反馈给我们,我们将酌情改进修正。
如果问题还未解决,请联系售后技术支持。