1 of 1 people found this helpful
Hi Eduard - You don't tell us about the PI server machine. More info would help. PI server utilizes caching both via it's own archive cache and the Windows file system cache. For both of these actors, more memory is always better. (Modern PI Systems leverage and benefit from more memory than ever before. Recommendations in our hardware sizing calculations are only minimums.) What does the underlying disk system look like? if the PI server is a virtual machine, what is the architecture for the storage system(s)? How many CPU cores for your PI server? (PI 2010 and PI 2012 server versions leverage more threads than before.)
Hello Chuck - Thanks for the help. We are talking about a DL380 G7 physical server. I have asked our customer for more details on memory and CPU. I'm quite positive it has a sufficient number of cores (i guess 12). Would memory play a big role for fetching data from disk, or just to enlarge the amount of data that can be cached (decreases probability that we have to go to disk)?
1 of 1 people found this helpful
Reprocessing archives would improve performance for sure (random vs sequential read from drive).
Is this is a 32-bit or 64-bit PI Server?
I would recommend monitoring at least these performance counters during the un-cached data queries.
PhysicalDisk (<drive>)\% Idle Time
PhysicalDisk (<drive>)\Avg. Disk Read Queue Length
PhysicalDisk (<drive>)\Disk Read Bytes/s
PhysicalDisk (<drive>)\Disk Reads/s
Make sure you're actually monitoring the correct drive! Nowadays,HDD is by far the slowest component of a computer system. If you can, upgrade to solid state drive and make sure you've enough memory to be able to hold reasonable time-range worth of archives.
Thanks Lubos. I asked our customer to check these performance counters.
Are you using PI OLEDB Provider to query make your aggregate and piplot queries? PI OLEDB Provider uses PI SDK at the back-end to get data from the PI server. Perhaps one good way to find the bottleneck would be to enable logging:
- Client side logging: you may force PI OLEDB provider to log to the local PI SDK Log. To do this you may use the tool "LogOptions" found under PIHOME\OLEDB\Tools\log viewer\logoptions.exe. It also possible to specify the log level and log file in the connection string. For more information, you can refer to the PI OLEDB User Guide. If you are using PI SQL Commander for testing, you can also specify the log levels there.
- Server side logging, you may check the messages in the PI server message logs.
From the time stamps in the logs, you might be able to identify the bottleneck for your query. Based on your description so far, it seems like the bottleneck might be on the PI server itself, when the data was getting retrieved. What is the memory and CPU usage on the PI server when the query is executing? How much memory is consumed by the PI archive subsystem? Are you running multiple queries in parallel? Are all the archive threads in use?
Apart from system limitations, faster query times can sometimes be achieved by (depending on the bottleneck):
- Make query when PI server is not busy handling other client requests (Did you noticed longer query time during middle of office hours?)
- Make query when network is not busy
- Structure the query efficiently (You can refer to this white paper for more information on how to structure efficient queries.)
Regarding your question about performance between PI 2010 and 2012, PI 2012 definitely has performance improvements over PI 2010. Perhaps you can check out the release notes for some information.
Like many other performance issues, the best way would be to pinpoint the bottleneck. Hope it helps! Keep us posted about your progress!
Thanks Daphne - useful suggestions. We will give them a try!
It's been a while since we spoke about this issue but I would like to know if you have found the solution to your problem?
I am marking this question as assumed answered. but do not hesitate to post again on this thread if you need further help.