SQL Reporting Services: What does that “Thread pool pressure” warning mean?
SQL Reporting Services Add commentsSome people love to review logs. For an even smaller group, log reviewing becomes a compulsion. For those of you who fall into either bucket (or even for people like me who only look at logs if my server is spinning in circles like Regan from the Exorcist) you may occasionally see this:
w3wp!runningjobs!5!6/1/2008-12:00:00:: w WARN: Thread pool pressure. Using current thread for a work item
So, what does it mean? I attempted to explain this message to a colleague the other day, and then John Gallardo, an SDE on the SSRS team did a much better job. Here is the essence of what he said:
When a report is processed by Reporting Services, we do our best to separate the work it takes to persist “report meta data” (my words, not his) like the snapshot we store in reportservertempdb and the work involved in actually getting a report to your users. Doing so gets the report back to the user faster. Essentially, we save that snapshot data asynchronously on a different thread from the main report request whenever there are available threads to do so.
If your system is under pressure we don’t grab another thread to do this “dirty work”. Instead, we synchronously process both the report and do the additional work on the same thread. The net result for you is that normally your report will take longer to get back to the requester because they have to wait for extra tasks to finish up before the report is delivered.
October 9th, 2008 at 7:46 pm
So, what changes can be made to help the server out and avoid this. Is it system memory, processor speed, or disk space? I want to have my reports back as fast as possible, so when I see this I’d like to know how it can be addressed.
October 10th, 2008 at 1:17 am
Great question, and I’m not 100% sure. I’d assume this is processor-related since we’re talking about threads – but am not sure. Let’s see what I can dig up back at the office…
November 17th, 2009 at 9:05 pm
Did you dig out anything back at the office ?
December 1st, 2009 at 9:53 am
Did you manage to dig anything out back at the office? We’ve experienced this issue recently and it would be great if you could confirm if it is just CPU related.
December 1st, 2009 at 5:42 pm
Sort of.
The tasks that the blog mentions are serviced by a background thread pool where possible. Only a certain number of threads can be spun up in that pool because we don’t want to “swamp” the CPU by spinning up too many.
If a task which might otherwise be serviced by that thread pool needs work and the maximum allowed threads are currently being used to do other things, then the threadpool message gets thrown and there is no “hand off” to the threadpool – the work gets done on the CURRENT thread.
So yeah, we’re dealing with threads and therefore the CPU, but it doesn’t necessarily mean the CPU is under pressure…just that we’ve maxxed out the background threadpool.