@袈裟和尚: 大哥 时间过去那么久了没有多正常啊
In general, in the case of IIS processes each process has a limitation of the used for it data - memory for the IIS process. During the report generation the data and the newly created resources by the report are held in memory, thus the machine should have enough memory and CPU to handle the amount of data and the document processing.
Our concerns about rendering large amount of pages are already known. My colleague has explained them here. Performance Considerations- the updated link to our performance considerations article, where you can find suggestions how to optimize the report.
You can implement custom paging where data is obtained in smaller pieces(e.g. 20 records). For the purpose you can use custom UI which on update passes updated parameter's values to the viewer's ReportSource.Parameters collection. The ReportSource.Parameterscollection is mapped by key(name) to the report's ReportParameters collection.
The above will be used only for previewing the report. On export you can use again custom UI and export programmatically a separate instance of the report bound to the whole data. This will save you resources from processing the same report twice - for preview in the viewer and export.
Test also to enable the cache for the viewer to save memory - Cache Management.