I have SQL Server 2008 R2 with SSRS. I have created an SSRS report that may contain up to 3,000,000 rows.
When I tried to generate such huge report I saw the following picture:
The stored procedure (one that brings the data into the Report) worked 50 seconds
After this the SSRS ReportingServivesService.exe started to consume a lot of memory. It's Working Set grew up to 11 GB. It took 6 minutes; and then the report generation failed with the following error message:
An error has occurred during report processing. (rsProcessingAborted)
There is not enough space on the disk.
“There is not enough space on the disk.” – this was probably about the disk drive on that server where the Windows page file was mapped into. The drive had 14 GB of free space.
A NOTE: the report was not designed as a single-page report. It is divided on pages by 40 rows. When I try to generate the same report with 10,000 rows – it takes just 1 minute.
The question is: can this be fixed somehow?
SSRS is extremely ill-suited for this kind of scenario. Tools like BCP or SSIS seem much more suited to this task. The question you ask ("can my situation be fixed") is not quite answerable, apart from being answerable by you by demonstrating that it can be done.
In my experience though, I wouldn't think of trying to get 3 million rows to work in SSRS.
If you insist or are compelled to try anyways, here's a few things you can do to improve the situation:
Dive in to the rdl and remove everything you don't need: font instructions, dimensions, images, etc. Check regularly in the designer if the file is still valid. You could even consider rebuilding the report with as little extra features as possible.
Move any expression or dynamic ssrs bit to the query.
Remove all formatting and formats for cells.
Increase disk en memory space. If you are compelled to generate such big reports in SSRS you're gonna need it. Close any other application you can, your PC or Server's gonna need all the resources it can get for this. Normally I'd consider this a non option / as an indication you need different tooling though. But I'm beginning to sound like a broken record :)
Choose the export format wisely. Excel or PDF is gonna take many additional resources, e.g. CSV renderer will be much friendlier.
Related
I did my best to create huge report for someone who still likes to work with 200K rows Excel file rather then to get some useful summary. Report is pretty simple SQL-wise but because of load and probably rendering time it time out on the server. I don't have any option to change time out value on server.
What is good way to solve this task: i.e. to create 40mB Excel for user via subscription or posting.
All SQL performance attempts already exhausted. Should I move to SSIS which I think can handle such task.
I'm on SSRS 2016
Thanks
Mario
I have a stepped report that has 5 row groups. Each one uses an expression as the value to group on. The user selects a value for up to 5 different parameters and based on those parameters is how the report is grouped.
With certain combinations of parameters the report may take 2min + to run in the preview pane in Visual Studio. When I deploy the report to the SSRS server the same combinations of parameters runs in 10 seconds or less. Out of curiosity, I created a copy of the report and removed the expressions from each of the row groups and specified a field to group on. In that case it previews just as fast as when viewed on the server.
Anyone have any idea what may be going on here?
I'm currently using Visual Studio Enterprise Update 3.
I realize this is an older issue, but maybe this will be some help to you.
I am experiencing similar symptoms to what you have described and it comes down to using dynamic fields in grouping statements. Apparently, any other statement can use dynamic fields without issue, but groupings incur a huge performance hit.
This link outlines the symptoms and causes.
I don't know if it was in that particular link or not but I read something about how the ReportViewer control when it renders to HTML has a bug in it that only happens when the control is running under .Net 4.0 or higher. In .Net 3.5 the performance is pretty much the same as it is if you were to run the RDL in the Report Viewer application.
If you are able to do so, the quickest way to get the report viewer component to work is to have the application pool IIS is using to run under .Net 2.0 (or 3.5 if that option is there, since they're basically the same thing).
If your application uses .Net 4.0 or higher for other functionality, there isn't much I've been able to figure out, short of rewriting the report to remove dynamic references from groupings, but that significantly reduces the interactivity of the report (no expand/collapse options in table rows/columns).
For reference, I had a report, where the query took about 2 minutes to execute, and then rendered almost instantly afterwards if I loaded the RDL in SSRS. That same report rendered using the ReportViewer control in .Net 2.0 took about 2 min 30 sec to fully render. Using the exact same code, but changing the app pool to use .Net 4.0, the report has been "rendering" for roughly 15 minutes now and still hasn't come back.
First of all and a bit obvious, if you are running your report in a development machine it won't have the same computing power as a server. Even if you are running VS from the server it won't run as fast as a deployed report.
The cause -as you may notice- for the slow performance is the grouping expression. It seems your report is taking to long to process so check this article from a Technet post. I copied and pasted a paragraph below:
Many levels of nested and adjacent groups in a Tablix data region can
affect report processing performance. Consider both the level of
grouping, the number of group instances, and the use of aggregate
functions which require evaluating after group, filter, and sort
expressions are applied.
I recommend you try to perform the grouping in the datasource at SQL level, you can also pass parameters to the query to set the desired grouping there.
Let me know if this helps.
My system
Windows 7, 64 bit
Microsoft Visual Studio Community 2013. Version 12.0.40629.00 Update 5
The question
I'm just getting started with SSRS, and I'm swicthing alot between Design and Preview mode.
It frustrates me that this is taking a bit long, particularly when I'm only adjusting the sizes of graphs and tables etc. Is there any way to preview the report without reloading the data?
Unfortunately there is no way to preview without running the queries. This is because if it doesn't run a query it (and you) don't know what data to expect and what the report should therefore look like.
Imagine if you were returning a textbox colour from your query for example. Without running the query the report would have no idea what colour the textbox should be.
To speed up the time to generate the preview is it possible to run the query against less data so it executes faster? For example against a sample set of data from your database which is only 10% of the total rows from your production db?
I have created a report with Report Builder 3.0
I'm running it on Microsoft Reporting services 2012
When O look in the performance logs (via ExecutionLog3) I see that all 3 phases(Retrieval, Processing, Rendering) took about 2 secs. But the browser take 7+ sec to present it (and it is consistent that there is 5-10 seconds overhead), what might be the source of it?
Could be one of two things most commonly:
The problem MAY BE, not sure, that your SSRS server is recycling every 12 hours and the first report of the day may be accessing the catalog on the ReportServer, getting the site up and running and then giving you a report. Generally this is common with SSRS and sometimes may take up to a minute for the first report of the day. Generally you can create a 'keep alive' service to poke SSRS every few hours at http:// (servername)/ReportServer which is SSRS's web service. You can also I have read set a config setting on the SSRS server itself but that never worked for me so I gave up and created a keep alive service instead.
The report can be taking a long time if a developer created a lot of functions on top of the data to render it with font changes, size changes, color changes, dynamic logic. You mentioned 'Rendering' in the time you looked up but if the report is not rendering in the browser how are you seeing rendering happen faster?
Generally it is both of these things in different situations. Best way to check 2 is create a super simple report with no parameters and a simple dataset that returns a black and white grid.
We have some SSRS 2005 reports, hosted on a report server. When we try to export the reports to excel its taking more than usual time to download. The reports otherwise takes acceptably reasonable time to render.
When i ran SQL profiler against the report server found that, it internally is calling "ReadChunkPortion" sp thousands of times. I am assuming this has something to do with the pagination.
Can we conditionally disable pagination, while doing an export ? Appreciate any help/directions.
You may have luck changing the InteractiveHeight property to 0, as described in the last sentence on this page. This may affect the way the HTML renders, though, so be aware of the impact it might have.
In my experience, SSRS exports to Excel are generally inefficient, and the bigger the dataset the more frustrating it gets. It seems like there is little you can do to change this.
If setting the InteractiveHeight property doesn't work, and you really need the Excel export to run faster, you may just have to export to a .csv then open in Excel. Unfortunately, it requires more steps from the user, but depending on the size of your report, it could still be faster than sitting and waiting for the Excel export to complete.