sm.ini / sm.cfg - Limiting CPU usage of operators? (603 Views)
Reply
Occasional Contributor
chris062689
Posts: 8
Registered: ‎02-18-2013
Message 1 of 4 (603 Views)

sm.ini / sm.cfg - Limiting CPU usage of operators?

We are having issues with users attempting to create custom views that spike the server's CPU usage.

There are also times where the users crash due to a SOAP fault.

 

This is causing "zombie" sessions to appear, with high CPU usage.

 

Is it possible either through the sm.cfg or sm.ini, or through the idle service, to keep track of each operator's CPU usage and kill their session if it gets higher than x%?

I notice there is the SYSTEMPERFORMM1 table, but it doesn't appear to be regularly updated, and there doesn't appear to be any way of querying it through javascript.

 

Thank you for your time.

Honored Contributor
Jacob Heubner
Posts: 4,177
Registered: ‎07-21-2008
Message 2 of 4 (576 Views)

Re: sm.ini / sm.cfg - Limiting CPU usage of operators?

I don't believe there is a way to do that per user.  Even the system performance monitor, which is supposed to do a general system health-check, won't accomplish it, because that wouldn't tell you how much CPU each user is using.  I don't even think that's possible, as each servlet carves out memory and CPU space per servlet, not per user, so there wouldn't be a way to track which user in the servlet is chewing up the CPU.

 

What works better (in my opinion) is removing the ability for most users to create views.  Don't give this out to everybody - epecially at the start of an implementation - because most people are not going to create good and useful queries. 

 

What most people seem to want to do is export reports right out of a record list in HPSM, which isn't a good idea as HPSM is meant to be a workflow tool and not a reporting tool.  So, they create complicated queries, thinking that will get them the reporting data they need.  Don't let them do that, and, as much as you can, mitigate that attempt by limiting which users can create the views.

 

You can do it a couple of ways; you can have particular members of the assignment group create a view that is shared by everyone in the group; train those users on how to create views that won't break things.  Or, you can have a kind of administration team - the same group that would request a new operator record, or an operator be moved from one team to another, or the daily non development, non break/fix work within HPSM handle view requests like service requests, acting as a buffer for the crappy queries that will cripple your system.

 

What you don't want to do is give the ability to create views to every operator in HPSM, or you won't be able to keep them from writing stuff that will break things - at the very least, their own HPSM session, or worse, an entire servlet or app server.

Respected Contributor
brav0
Posts: 931
Registered: ‎12-07-2008
Message 3 of 4 (569 Views)

Re: sm.ini / sm.cfg - Limiting CPU usage of operators?

Chris,

 

There is a parameter called maxmemoryperthread which is introduced and can specify the maximum limit of the session memory. When the max limit is reached, it termintes the user session.

 

You could try to get some details on this system parameter.

 

Thank you

DJ.

I am Listening..
Honored Contributor
Piku
Posts: 4,128
Registered: ‎06-17-2010
Message 4 of 4 (559 Views)

Re: sm.ini / sm.cfg - Limiting CPU usage of operators?

Hi

Agree with Jacob.

But you can try for 'systemperformance' , it do capture some records for each process and user's memory &cpu utile etc.
It have some record,s do not know at what frequency it captured. You can save these records in different table using scheduler at desired time interval.

You can also add trigger on view table with 'on add' condition so that it will capture that user details from 'systemperformance' in some table.

hth,
____________________________________
Assign Kudo, if found post useful and mark it accepted if solves the issue.
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.