如果Reporting Service偶尔出现不可访问或访问出错情况，这种情况一般没有做监控的话，很难捕捉到。出现这种问题，最好检查Reporting Service的日志文件。
今天早上就遇到这样一个案例，应用程序监控到调用SQL SERVER 2005的Reporting Service出现Method failed: HTTP/1.1 500 Internal Server Error 。检查C:\Program Files\Microsoft SQL Server\MSSQL.3\Reporting Services\LogFiles下的日志文件，发现出现问题时段，有如下错误信息：
w3wp!runningjobs!1!8/4/2015-08:50:58:: w WARN: Thread pool pressure. Using current thread for a work item.
w3wp!runningjobs!1!8/4/2015-08:50:58:: w WARN: Thread pool pressure. Using current thread for a work item.
w3wp!runningjobs!1!8/4/2015-08:50:58:: w WARN: Thread pool pressure. Using current thread for a work item.
w3wp!runningjobs!1!8/4/2015-08:50:58:: w WARN: Thread pool pressure. Using current thread for a work item.
w3wp!runningjobs!1!8/4/2015-08:50:58:: w WARN: Thread pool pressure. Using current thread for a work item.
w3wp!runningjobs!1!8/4/2015-08:50:58:: w WARN: Thread pool pressure. Using current thread for a work item.
w3wp!runningjobs!1!8/4/2015-08:50:58:: w WARN: Thread pool pressure. Using current thread for a work item.
关 于这个告警信息，网上有不少资料建议调大IIS下面的应用程序程序池（Application Pools）下ReportServer以及ReportService的最大工作进程数（“Maximum number of worker processes"）参数。这样就能扩大同时并行处理的报表数量。
if you are using IIS 6, you can increase the number of worker processes for the Report Server application pool. You can use this value to scale up the number of reports you can run concurrently. So the number you would need is approx. max. number of concurrent requests * number of concurrent database fetches in report.
那么如何设置最大工作进程数（“Maximum number of worker processes"），有篇文章介绍了下: 按核设置最大工作线程数。 但是由于有些服务器上面还部署有其它应用，还是要根据具体应用场景设置，设置完成后监控性能计数器（ performance counters ）来判断设置值是否合理。
Some searches brought back some information suggesting increasing the number of worker threads but other than a description of what the warning meant not much else.
There was one post which suggested one process per socket, that would equate to 4 on our servers, but that didn't seem much change especially as one of our servers was set to 1 and the other to 5.
I suggested we should set this to at least 1 per core which would give us 16 and then monitor carefully. My colleague had done some research about queues and put up some performance counters to watch this alongside process explorer to actually see how many processes fired up.
