|
|
Rank: Member
Groups: Member
Joined: 9/23/2008
Posts: 15
Location: Pennsylvania, USA
|
We have a bad process book display floating around our network that causes our piarchss subsystem to become responsive. It asks for a very large amount of data every 10 seconds. Does anyone know of a good way to prevent a bad process book or similar request from running? Or at least a way to stop/time it out? Right now we have to manually kill piarchss and restart it. Until then all the new data is queued and nothing is archived.
Thanks,
Matt
|
|
|
|
|
OSIsoft vCampus is a subscription-based, online offering that consists of providing everything people need to develop applications on the PI System. We invite you to take a "tour" of the OSIsoft Virtual Campus - also feel free to consult the FAQ or contact OSIsoft vCampus for more details.
|
|
|
Rank: Administration
Groups: Administration
Joined: 6/20/2008
Posts: 612
Location: Cheshire, United Kingdom.
|
Hi Matt, Initial reaction would be to study the message log for the PI server to see if you can identify any connections either application/users/ip addresses that are connecting before archss crashes (becomes unresponsive) or there abouts. If you get an ip you can trace the user logged onto the machine etc Have put thinking cap on... Principal Consultant
Real-Time Data Management @ Wipro Technologies
|
|
|
Rank: Administration
Groups: Administration
Joined: 6/20/2008
Posts: 612
Location: Cheshire, United Kingdom.
|
Right Matt...looked through some of my notes form previous clients and have some recommendation, however without being able to see specifics of your PI system it is hard to know if these will work - be sure to check with OSI Tech Support too if you are unsure with anything. Timeout parameters... ArcMaxCollect - limit the number of compressed events that can be retrieved by a single query for a given client. The default is set to 150,000 events. From what I remember (need to check OSI documents) this parameter does not affect archive summary data. (name of subsystem)__MaxThreadsPerClientQuery - limits the number of threads a single client can use concurrently for the same query. Refer to your PI Server Reference Guide from OSI for full explanations of the timeout parameters but these should help until you get to the bottom of the rogue client - well at least prevent archss crashes. Principal Consultant
Real-Time Data Management @ Wipro Technologies
|
|
|
Rank: Member
Groups: Member
Joined: 9/23/2008
Posts: 15
Location: Pennsylvania, USA
|
I know what file it is. It was fixed but some old copies are still out there. I'll do some more research into the tuning parameters.
Thanks!
|
|
|
Rank: Administration
Groups: Administration
Joined: 6/20/2008
Posts: 612
Location: Cheshire, United Kingdom.
|
Just a thought - do you use a specific PI user to log in for that file? Could you not change the PI user for the new/working file and flush out the old file? Principal Consultant
Real-Time Data Management @ Wipro Technologies
|
|
|
Rank: Advanced Member
Groups: Member
Joined: 7/23/2008
Posts: 38
Location: Cheshire, UK
|
Hi Matt,
In anticipation of such issues we adopt a regime of controlled access to our PI servers. ProcessBook and other client tools are rolled out only on business request and then during the install each user is set up with a specific account and password which is recorded in our files along with their PC node name. Using this information we create accounts and trusts as necessary within PI.
Whilst this adds marginally to the admin, it does allow us to maintain control of what is out there and who has access. In the event that we should encounter problems we can interogate the message logs to see who and what was accessing the PI server at the time of those issues.
We developed this approach after talking to other PI system admins who noted one of their biggest headaches was the fact that anyone and everyone could install the PI client tools and tended to use a default PI User account. Not only did this allow the number of displays being built to an unmanagable number, but users could do anything they wanted within the context of the tools they had which wasn't always PI server friendly.
Regards,
Burnikell1
|
|
|
Rank: Advanced Member
Groups: Member
Joined: 7/16/2008
Posts: 35
Location: UK
|
Burnikell1 wrote:
We developed this approach after talking to other PI system admins who noted one of their biggest headaches was the fact that anyone and everyone could install the PI client tools and tended to use a default PI User account. Not only did this allow the number of displays being built to an unmanagable number, but users could do anything they wanted within the context of the tools they had which wasn't always PI server friendly.
Regards,
Burnikell1
I hate to sidetrack this topic, but this is something we experience a lot of, and I must ask....does the license permit anyone on a site to install the client tools (such as Datalink) or are these licensed per machine? PI SMT is currently really missing a nice user monitoring tool.... Who ate all the PIs?
|
|
|
Rank: Administration
Groups: Administration
Joined: 6/20/2008
Posts: 612
Location: Cheshire, United Kingdom.
|
MacaroniPI wrote:
PI SMT is currently really missing a nice user monitoring tool....
This is because OSI have IT monitor, which ships as a seperate product hence more £'s. There are a lot of built in performance counters, SNMP etc that can be used to build a good picture of what devices are attached to a server. What would be nice is total PI user connection statistics with associated IP address and application process/thread being used and updated in real time. This would be a very useful tool, especially if you could kick any bad connections for users overloading the PI system. For example: piadmin (12 users) --> 255.255.255.255 | Europe\RJKSolutions | PISMT.exe (v3.2.4.0) --> 255.255.255.255 | Europe\RJKSolutions2 | MyApplication.exe --> 255.255.255.255 | Europe\RJKSolutions3 | Excel.exe (PI-DataLink v3.1.6) ..... pidemo (132 users) --> ..... Principal Consultant
Real-Time Data Management @ Wipro Technologies
|
|
|
Rank: Advanced Member
Groups: Member
Joined: 7/23/2008
Posts: 38
Location: Cheshire, UK
|
Hi MacaroniPI,
Haven't tried it myself but there is a utility (ProcessBook Add-In) available on OSIDN called 'Display Usage Log User’s Guide' .
The blurb is:
[i]The Display Usage Log add-in logs ProcessBook display activity in a string tag on your default PI server. It writes the Windows user's name and the file path for each ProcessBook display opened on your computer, and then stores this information in a PI string tag.
The download also includes a spreadsheet that consolidates this data into a report that can help you learn which displays are most important to your users, and identify your most important users.[/i]
As I said, haven't used myself so don't have any info on versions of PB it works with, its limitations or how useful it really is.
As for licenses - it depends on your deal with OSI.
Regards,
Burnikell1
|
|
|
Rank: Member
Groups: Member
Joined: 9/23/2008
Posts: 15
Location: Pennsylvania, USA
|
We do create a user account for each user based on their network id. Unfortunately there are a couple cases where more generic pi users are used. Because the computers are running 24/7 without any particular person loggin in. I did find an enchancement request for SMT that would provide exactly what I am looking for. I sent OSI an email asking on the progress of this issue.
Issue No. 9271OSI8
Product SMT3
Module NetworkManagerStats
Found in Version N/A
Fixed in Version (Targeted)
Targeted in Version 3.2.0.0
Severity 2-Moderate
Summary
NetMgrStats> Support the 3.4.370 rpc to forcibly disconnect a user
Description
N/A
Workaround
N/A
|
|
|
Rank: Member
Groups: Member
Joined: 9/23/2008
Posts: 15
Location: Pennsylvania, USA
|
Here is one method of finding out who is slamming the PI Server. http://techsupport.osiso...619b0153b9fab10ab1c.htm
Disconnecting the user is still not real easy but I found this to be useful.
|
|
|
Rank: Administration
Groups: Administration
Joined: 6/20/2008
Posts: 612
Location: Cheshire, United Kingdom.
|
Matt, thanks for the pointer to tech support. Actually explains the process to remove those users very well, should be no issue for OSI to add this to PI-SMT. In fact, should be no issue to create your own GUI for this too. Principal Consultant
Real-Time Data Management @ Wipro Technologies
|
|
|
Rank: Member
Groups: Member
Joined: 9/23/2008
Posts: 15
Location: Pennsylvania, USA
|
I also thought it would be pretty easy and did some snooping around. That table is not accessabile in PIOLEDB (at least through the MMC PI OLEDB Plug-in). I can't find anything to do this in the SDK. Those are the tools that I know best. I've never used ODBC or API so I'm not sure.
|
|
|
Rank: Administration
Groups: Administration
Joined: 6/20/2008
Posts: 612
Location: Cheshire, United Kingdom.
|
You may need to delve a little deeper than SDK/OLEDB, I better check with OSI before violating any copyrights etc....watch this space. Principal Consultant
Real-Time Data Management @ Wipro Technologies
|
|
|
|
Guest
|
