oracle wait event:PX Deq Credit: send blkd
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.
---------------------------
Comments:
Thanks, Tom.
Recently I troubled that problem.
I understand it.
but, our system don’t use insert ~ (select /* parallel */) statement.
We just use “select” statement
SELECT ROWID, ORA_ROWSCN,S_SUID,S_DATE FROM STG_WEBLOG_DAY_1;
stg_weblog_day_1 is a partition table and object’s degree is 16.
we can see the “PX Deq Credit: send blkd” message in the top wait events.
what is the problem???
Comment by kahye — January 6, 2009 @ 10:43 am
------------------------------------------------
There is not necessarily a problem. Just if the waits are too high (constantly high) it might be a waits of resources.
How many cpu’s or cores does your system have?
If it is a batch system with only one or two session, I would care too much. If you more session and you need constant performance you may lower the parallel degree on the table.
Another thing you could check how your system is loaded (system load, context switches). If you load is constantly much higher as your cpu/core count i would lower the parallel degree as well.
from:http://www.asktherealtom.ch/?p=8
another resource: rac temp PX Deq Credit: send blkd