Question
Most of the services throws Pega0011 aklerts in AES Top service items
we have recently installed AES 7.30 in our Dec\Test server and we found that most of the services are coming under low performance items throwing pega0011 Alert including AES soap services. When i checked the services with some sample requests, it processed quickly and did find any performance issue .
I could see server health is critical because of this service performance issue. Kindly advice what could be the reason behind it
***Edited by Moderator Marissa to update platform capability tags****
Please find below details for Pega0011 Alert.
KPI value is around 10k wherein KPI threshold is 1k,
PAL Statistics : TotalReqTime is 9.7 ; TotalReqCPU is 3.03 ; ServiceInMapReqElapsed and ServiceoutMapReqElapsed is 0
InputBytes is 120 wherein output bytes is 1000 ; RDBIOcount is 4 and otherIOCount is 2.
As you see there is huge difference in KPI value and functionality is also not affected, not able to see the cause for this issue.
Could you please suggest any solution for this. please note that for some services, it throws PEGA0042 and PEGA005 along with PEGA0011.
Pega0011, Pega0042 and Pega0005 all are interrelated only.
Pega0011 is time taken from Pega receives a request to send the response.
Pega0042 is for packaging the DB query
Pega005 for Query taking a long time.
You can see the queries, see which rule is causing them. Try to optimise the query if possible.
Actually this issue is happening OOTB SOAP service(AES) operations too , which was shown as top service items in AES.
it was taking around 3000 ms whereas threshold is 1000 ms. This is where i thought some basic configuration might have missed in prconfig xml or DASS settings?
AES server is fresh installation and i couldn't see any threshold settings in prconfig.xml for alerts\exception thresholds. Kindly advice if i need to add any appenders to resolve this issue
I did little research but couldn't find any prconfig change required as per AES guide and some related documents.
So for now to resolve the issue, you can actually use in prconfig.xml
<env name="alerts/services/totalRequestTime/threshold" value="xxxx" />
Are the request time and the threshold time having a huge difference? If not you can change the threshold time accordingly since you see no functionality loss.