Just a few days ago a got to two Oracle DBAs discussing why the have so much “PX Deq Credit : send blkd” on a system. And if that is causing their performance problems.
The are some blog on the internet claiming it has to do with qc distribution and what ever.
But in many cases, especial if you experince huge waits on “PX Deq Credit : send blkd” the explanation can be much simpler. But first some background information.
If a query is run in parallel there is a query coordinator (QC) and the query slaves. The slaves do the actual work an send the result to the query coordinator. This is done through message buffers which you specified with the parallel_execution_message_size.
This buffer exists in the large or in the shared pool depending how PARALLEL_AUTOMATIC_TUNING is set.
Metalink states about the PX Deq Credit: send blkd event:
This is considered as idle wait event.
You should investigate the sender (decode the senderid).
There is no general advice to reduce the waitime for this event.The process wishes to send a message and does not have the flow control credit. Process must first dequeue a message to obtain the credit. Indicates that the receiver has not dequeued and/or completely consumed the prior message yet.
From that statement you could believe that is a idle even an you don’t need to care.
In this case the waits were cause by a query which look similar to this:
insert into tablex values (select /*+ parallel(32) +*/ * from tabley);
Now it pretty clear from where the waits are coming. Since parallel query is enabled by default, but parallel dml is disabled, you feed a single insert process with 32 slaves. the insert process can never consume that much.
So the question is now, does that indicate a performance problem?
Yes, I does!
- It indicates that your developer didn’t perform right. He played with parallel query without knowing what he does.
- It eats your memory and produces unnecessary process on your system. If your system is not loaded anyway the impact may be minimal. But still you waist system resources and on a loaded system the impact may be considerable.
What could you do now?
- Don’t run the sub query parallel – it will not run faster, but it does not waits resourced.
- Enable parallel DML. This is not that easy. You would to have verify if your application can work with parallel dml, because there are many restrictions.
- Just ignore it. If you don’t have a performance problem there is no need to fix it.
