.NET线程池最大线程数的限制-记一次IIS并发瓶颈

.net threadpool 最大线程数的限制

iis并发瓶颈，有几个地方，iis线程池的最大队列数，工作进程数，最大并发数。这些这里就不展开。主要是最近因为过度使用task 导致的线程数占用过多，所以实验了一下 .net线程池 的限制，分享一下。

注意iis线程池与.net线程池不是同一个东西，下面详解。

 w3 thread pool(w3tp)

当处于内核模式的http.sys接收到来自用户的请求之后，会将请求放入队列中。那处于用户模式的w3wp进程如何从内核模式的队列中取出请求呢？

w3wp中有专门干这个的——w3dt+w3tp。

当请求被w3tp通过w3dt从http.sys的队列中取出来后，接下来的工作就会转交给asp.net，线程池——.net thread pool。

 为了检验.net 线程池 最大线程数的限制，在mvc中新增一个action 如下

 

 每个task sleep 1s ，这样线程池就会被占用最多20w条线程。

 

 设置.net线程池 的配置文件位置

 c:\windows\microsoft.net\framework\v4.0.30319\config\machine.config

64位系统：

c:\windows\microsoft.net\framework64\v4.0.30319\config\machine.config

找到这个节点 processmodel

设置maxworkerthreads =20

autoconfig=false （win10默认是true）

 

 

 访问地址：/home/testtasklimitcount  时

使用工具集 sysinternalssuite procexp64.exe 查看系统进程的详细信息

看到w3wp.exe 这里的总进程数卡在100左右，因为我这里的4个cpu，所以maxworkerthreads *cpucount =80  另外的27条线程可能是iis线程池里的。

然后当我们同时访问该站点其他url时，全部都在一直在等待了。

 

 

 

 ok，重新改为

 

 

maxworkerthreads =200

这个时候重新启动站点，运行/home/testtasklimitcount 时，看到进程数很快累加到400-500之间，这个时候线程池并没有被用满，只是有些task任务结束后丢回线程池后又被重新启用。

 

同时再次访问一下该站点其他url，发现虽然加载速度稍有缓慢，但是ok没问题的。

 

 

 这个值（workerthreads）最好根据机器性能自行配置，一般100左右，minworkerthreads 也很重要，因为开启线程的速度其实还挺慢的，每秒可以开启几条而已，所以预先设置好minworkerthreads，可以预防一些突发流量。