OACore issue: Oacore process the requests and consumes the memory from JVM heap.
Scenario 1: I have an application called oracle R12/oracle apps/Ebiz which has to support 300 users, expected response times are below 5 seconds. While ramping up the users, application performance is degraded at 100 user load. Even application itself crashed at 150 user load.
Process: Initially we started analyzing client side statistics and found that issue with server side. Then we analyzed OS/hardware/code/DB but we did not find anything. So moved to DB layer,
finally we found an issue with JVM settings which is a oacore settings (memory management configuration).
After analyzing oacore settings, we recommended them to tweak that setting from oacore = 1 to oacore = 3 which resolved the issue.
Cursor Limit Issue:
We have an application which has to support 500 users
Solution: We started test with 500 users but application got crashed at 150 user load and application performance degraded at 100 user load.
We have started analyzing client side, OS, hardware, memory, method, level statistics which didn’t provide any clue. Then we started analyzing configuration settings in HTTPD file in Tomcat Apache server and database statistics. Then moved to database configuration settings.
We found an issue with cursor limit which is causing application crash.
Process: We used dynatrace profiling tool to monitor all the layers of application including configuration settings as part of testing while ramping up users, cursor limit usage reported 100% at 120 user load. Then we asked DB team to provide the cursor limit setting which is reported 50. By default cursor limit is 50 which can accommodate only 100 users. We
recommended them to change 50 to 2000 as per oracle SGA, they can tweak to 1000 for that application. After deploying new build with 1000 cursor limit supported 500 users without any performance degradation.
Thread limit:
We found an issue server reached the max number of simultaneous connections in server log.
Cause: Not enough threads in Apache.
Statistics: Due to the connection pool settings, application is not able to handle simultaneous connections created by 150 users.
Recommendations: Increase the connection pool settings from 10 to 16.
Private Byte Issue:
Process: In one of my SAP application, users are causing memory dumps as per SAP
architecture, they configured private bytes 4mb memory. If the users are trying to retrieve more than 4mb memory, then the users will be pushed to run mode to debug mode. If SAP system allocates more memory, then the user will come back to run mode. To execute the report if the
system is not allocating the memory, the users will be pushed to error mode which causes the memory dump.
Recommendation: Recommended SAP people to reconfigure private byte settings.
DOP settings and many settings will be there.
Based on scenario and as per our requirement we'll took the changes from configuration side.
Scenario 1: I have an application called oracle R12/oracle apps/Ebiz which has to support 300 users, expected response times are below 5 seconds. While ramping up the users, application performance is degraded at 100 user load. Even application itself crashed at 150 user load.
Process: Initially we started analyzing client side statistics and found that issue with server side. Then we analyzed OS/hardware/code/DB but we did not find anything. So moved to DB layer,
finally we found an issue with JVM settings which is a oacore settings (memory management configuration).
After analyzing oacore settings, we recommended them to tweak that setting from oacore = 1 to oacore = 3 which resolved the issue.
Cursor Limit Issue:
We have an application which has to support 500 users
Solution: We started test with 500 users but application got crashed at 150 user load and application performance degraded at 100 user load.
We have started analyzing client side, OS, hardware, memory, method, level statistics which didn’t provide any clue. Then we started analyzing configuration settings in HTTPD file in Tomcat Apache server and database statistics. Then moved to database configuration settings.
We found an issue with cursor limit which is causing application crash.
Process: We used dynatrace profiling tool to monitor all the layers of application including configuration settings as part of testing while ramping up users, cursor limit usage reported 100% at 120 user load. Then we asked DB team to provide the cursor limit setting which is reported 50. By default cursor limit is 50 which can accommodate only 100 users. We
recommended them to change 50 to 2000 as per oracle SGA, they can tweak to 1000 for that application. After deploying new build with 1000 cursor limit supported 500 users without any performance degradation.
Thread limit:
We found an issue server reached the max number of simultaneous connections in server log.
Cause: Not enough threads in Apache.
Statistics: Due to the connection pool settings, application is not able to handle simultaneous connections created by 150 users.
Recommendations: Increase the connection pool settings from 10 to 16.
Private Byte Issue:
Process: In one of my SAP application, users are causing memory dumps as per SAP
architecture, they configured private bytes 4mb memory. If the users are trying to retrieve more than 4mb memory, then the users will be pushed to run mode to debug mode. If SAP system allocates more memory, then the user will come back to run mode. To execute the report if the
system is not allocating the memory, the users will be pushed to error mode which causes the memory dump.
Recommendation: Recommended SAP people to reconfigure private byte settings.
DOP settings and many settings will be there.
Based on scenario and as per our requirement we'll took the changes from configuration side.
No comments:
Post a Comment