1) rename the serverLog.txt file under PPM_HOME/server/SERVER_NAME 2) add the following parameters to the logging.conf file: com.kintana.core.logging.PRODUCT_FUNCTION_LOGGING_LEVEL=com.kintana.core.server com.kintana.core.logging.PRODUCT_FUNCTION_LOGGING_LEVEL=com.kintana.core.server com.kintana.core.logging.PRODUCT_FUNCTION_LOGGING_LEVEL=org.jboss.mq com.kintana.core.logging.PRODUCT_FUNCTION_LOGGING_LEVEL=org.jnp.interfaces 3) change the following parameter in logging.conf to DEBUG: com.kintana.core.logging.SYSTEM_THRESHOLD = DEBUG 4) Restart PPM to gather a fresh log 5) When the issue is replicated, please note down the timestamp 6) Then contact your DBA and request the AWR report at the time of the replication. 7) Please attached the server log file along with the replication timestamp and the AWR report.
More times than not, high CPU (either on the app server or database) is responsible for the slowness... There are three categories of performance problems
Database cpu (bad queries)
App server cpu (PPM is processing ton of data, maybe service related)
App server cpu (out of memory causes constant garbage collection.
I will start investigating your issue in specific to figure the next steps to try…
We need the following information from you:
8.0 App Server specs (CPU, RAM, HD space, OS, etc)
8.0 DB Server specs
9.14 App Server specs
9.14 DB server specs
9.14 DB AWR report
Latest kSupport.sh output
Try an index rebuild. Please engage your DBA on this and do it.
Please take a look at the "Improving Advanced Searches" section in the Installation and Admin guide, this will also allow us to improve the system performance: PPM Center users can search for requests based on custom fields defined in request types, request header types, and user data. Users can perform advanced searches to locate requests based on information that is defined as critical to business processes. As the number of requests logged increases, users performing advanced searches can experience slower performance. To improve performance during advanced searches, use the following guidelines: * Specify additional request header fields in the advanced searches. Header fields are automatically indexed by PPM Center, and therefore yield faster returns. * Add indexes to a limited number of detail fields, preferably fields that are commonly used in advanced searches. Take care not to add too many indexes, since this can affect the performance of inserts and updates to the database. * Set the DEFAULT_REQUEST_SEARCH_ORDER_BY_ID server configuration parameter value to true to remove the sort order column on a request search. Record sorting slows performance. * Change the value set for the REQUEST_SEARCH_RESULTS_MAX_ROWS server configuration parameter to restrict the maximum number of records retrieved. * For portlet search queries, lower the value set for the PORTLET_MAX_ROWS_RETURNED server configuration parameter. For most portlets, 20 to 50 records is adequate. The default is 200.
Another potential option to try in the Installation and Admin guide:
SORT_ELIMINATION_COST_RATIO: For certain restrictive (with good filters specified) and limited (returns few records) searches, PPM Center uses the FIRST_ROWS_N optimization mode. If a search such as this also uses SORT on one or more fields returned by the search, Oracle uses the INDEX on the sorted columns under the FIRST_ROW_N optimization, even if other indexes on supplied filters may yield to a better execution plan for a SQL statement. This often leads to a less desirable INDEX FULL SCAN on the index on sorted column. Recommended Setting: Set the parameter value to 5. This directs Oracle to consider an execution plan with ORDER BY sort elimination, as long as the plan is no more expensive than five times the cost of the best-known plan (that uses sort).
Also increasing the CPU power as recommended might help - have you checked the CPU usage on the PPM and database machines to see if they are currently overloaded. If the machines are not maxed out, increasing the CPUs is unlikely to have any effect.
-- Remember to give Kudos to answers! (click the KUDOS star)
Has anyone considered this might be a Daylight saving time issue? This just happen to me for the last week Starting Oct 29 and ending Today Nov 5. All users were having a very diffucult time getting to their dashboard... Links to request, reports and anything not related to portlets were working fine... Was about to reinstall whole production server from scratch this week and bam. No issues today and everybody asking me what I did to resolve. Of course I took all the cred and stated that the Jboss was moving way to fast for the JDK and once that was resolved all is well... ;-)