Parallelism is near to silver bullet for many of the database operation on huge volume of data. But as is the case with bullets, you have to handle them with care otherwise they could backfire.
PX Deq Credit: send blkd is a wait event you might see in your AWR report if you are running parallel queries. The event PX Deq Credit: send blkd happens when the parallel slaves compete for sending results back to the QC process. The competing slaves time out after 2 seconds. From the AWR reprot, get the avg wait time for PX Deq Credit: send blkd for the parallel slaves and see if it is less than 2 seconds? If it is then probably there is nothing you can much except controlling your parallelism in your application because heavy chances are that you are maxing out on your CPU.
If that is not the case, and your average wait time is higher than 2 seconds, and that is happening frequently and you are watching same patterns again and again in AWR or ASH reports during the high load on the system when the performance is not acceptable, and you believe that you have ample CPU then increase the size of PARALLEL_EXECUTION_MESSAGE_SIZE parameter and by also keeping the space in large_pool in perspective.
PX Deq Credit: send blkd is a wait event you might see in your AWR report if you are running parallel queries. The event PX Deq Credit: send blkd happens when the parallel slaves compete for sending results back to the QC process. The competing slaves time out after 2 seconds. From the AWR reprot, get the avg wait time for PX Deq Credit: send blkd for the parallel slaves and see if it is less than 2 seconds? If it is then probably there is nothing you can much except controlling your parallelism in your application because heavy chances are that you are maxing out on your CPU.
If that is not the case, and your average wait time is higher than 2 seconds, and that is happening frequently and you are watching same patterns again and again in AWR or ASH reports during the high load on the system when the performance is not acceptable, and you believe that you have ample CPU then increase the size of PARALLEL_EXECUTION_MESSAGE_SIZE parameter and by also keeping the space in large_pool in perspective.
1 comment:
Hi. The PARALLEL_EXECUTION_MESSAGE_SIZE parameter appears to be non-modifiable as stated in http://docs.oracle.com/cd/E18283_01/server.112/e17110/initparams178.htm. If we are on 11gR2, what do you suggest?
Post a Comment