AW: DB CPU and resmgr.cpu.quantum event in top 10 foreground events

From: <ahmed.fikri_at_t-online.de>
Date: Wed, 28 Oct 2020 12:10:19 +0100 (CET)
Message-ID: <1603883419348.39884.a74d5c1fa72f640f9fd76451457637c51d1486bd_at_spica.telekom.de>



 

Hi all,  

I found the reason for our performance problem: For some reason the cpu_count on the new instance was set to 16 (the old instance used 52). I overlooked this basic parameter at the beginning.  

Best regards
Ahmed        

-----Original-Nachricht-----
Betreff: DB CPU and resmgr.cpu.quantum event in top 10 foreground events Datum: 2020-10-27T20:20:04+0100
Von: "ahmed.fikri_at_t-online.de" <ahmed.fikri_at_t-online.de> An: "list, oracle" <oracle-l_at_freelists.org>      

Hi all,

after migrating a database from 11.2.0.4 to 12.1.0.2 we encountered some performance issues.

The AWR report is showing this:

Top 10 Foreground Events by Total Wait Time:

Event                      Wait          Total Wait Time (sec)              
   Wait Avg(ms)               % DB time        Wait Class
DB CPU                                   201.1K                             
                                           75.5
resmgr.cpu.quantum 930,919     33.7K                                       
36.22                           12.7                  Scheduler
 

I think to explain DB CPU would not be easy, but we have found by investigating other java program on the oracle server (Redhat ) that the ulimit was set to a lower value (1024). I'm not sure if this has to do with DB CPU time.  

Furthermore I checked the parameter resource_manager_plan and found following:

in the new instance (12.1.2.1 RAC) the parameter is set to MIXED_WORKLOAD_PLAN. Here we have performance problems in the old instance (11.2.0.4 RAC) the parameter is set to null. (Everything work as expected)
Maybe this could explain the 12.7% DB time for resmgr.cpu.quantum  

Has anyone encountered problem using this parameter set to MIXED_WORKLOAD_PLAN?   Best regards
Ahmed  



--
http://www.freelists.org/webpage/oracle-l
Received on Wed Oct 28 2020 - 12:10:19 CET

Original text of this message