2 of 2 people found this helpful
Here is a KB article that describes ArcMaxCollect which is the parameter I believe you are asking about. KB00367 - Changing the ArcMaxCollect parameter: What are the ramifications or possible issues?
Older servers that were upgraded most likely have a default limit of 150K and newer severs have a limit of 1.5 million as the default. This parameter is designed to protect the PI Sever from expensive queries. It is more likely that this data will be on disc and not on the primary archive so your'll see more disc activity and this data will be placed in the file systems cache on the Data Historian server. In general, 2 million events is not an unreasonable setting and you will still give you protection against large queries. An alternative to going up to say 10 million is to chunk your queries. A few other parameters you might want read about: 3224OSI8 - How to limit expensive queries to the PI Server archive
Thanks Dan. This KB articles are very informative .
Curious about case like question 2:
If my processbook trend or PI datalink fetching more data than maxArcCollect, then how it will be done?
Will my one call through processbook or datalink automatically converts into two concurrent calls or if otherwise than how?
Good question! No, PI Datalink and PI Processbook do not automatically convert into two (or more) calls if the limit is hit. You typically do not experience this issue in PI Processbook because it use the SDK method Plotvalues which only retrieves enough information to accurately display the trend. A PI ProcessBook DataSet requires all the archived values so it does not use PlotValues and is subject to ArcHaxCollect.
That was very insightful Dan
I have query that if I am developing custom application using PI Web API and I am fetching archive data of, as an example 6, assets for a month, then the query has to get 20 million around data. If my maxArcCollect is 10 million, then please advise me on how should I make query to get this data?
Option 1: Increase the maxArcCollect
Option 2: Divide the single query into two and call them concurrently
Please suggest if we have options except above two.
1 of 1 people found this helpful
If you always know the data density and approximately how many events it might make sense to do concurrent chunks to provide some protection to your PI System instead of increasing maxArcCollect. If users often need 10 million events, then maybe increase this. In most cases, the Chunking is slightly difficult to determine appropriate sizes since data density is not known ahead and we don't really have a way to page on this yet.
Little information need to be added here.
I was facing this issue when I am fetching PI tag data using PI Web API via streams like,
For bulk read via streamset please follow this thread .