Geeta,
There are many different delay queues in the database. When you say "delayed sessions in the delay queue" that you say you can see in Viewpoint, I believe you are speaking about the throttle delay queue. The throttle delay queue is on the parsing engine and is delaying requests before they begin execution.
The throttle delay queue is entirely different from the ResUsageSPS metrics WorkMsgSendDelay and WorkMsgReceiveDelay. I am assuming that those are the two metrics you are referring to when you reference "send delays" and "receive delays".
WorkMsgSendDelay and WorkMsgReceiveDelay have nothing to do with requests that are delayed by a throttle. WorkMsgSendDelay and WorkMsgReceiveDelay represent the time in milliseconds that a work message was delayed in being sent from one vproc to another, such as from the PE to the AMP, or being received on a vproc. Those are milliseconds of wall-clock time that the work message was either waiting to be sent, or waiting to get an AWT once it arrives on the AMP.
When you ask about the "delay queue" becoming a 3 or 4 digit number, it is not clear if you are asking about the throttle delay queue, or the time in milliseconds that a work message was delayed in getting an AWT (WorkMsgReceiveDelay). In either case, the object being delayed (in the first case a request, in the second a work message that represents a step in a request), no CPU or I/O is being consumed during the waiting.
If you are asking if it is problem if WorkMsgSendDelay and WorkMsgReceiveDelay reports 3 or 4 digit numbers in ResUsageSPS, it is not necessarily a problem. However, it usually is an indication of running out of AMP worker tasks or being in flow control. It would be better to monitor MaxInuse and MailBoxDepth in the ResUsageSAWT table to understand the severity of AWT exhaustion. What WorkMsgReceiveDelay data is useful for is when you want to find out what workload is being impacted by a shortage of AWTs. The workloads with the higher number of milliseconds in that field in ResUsageSPS are the ones that are being impacted the most by AWT shortages. Whether or not that is a problem for you depends on how you interpret that in your environment. If it is low priority work you may not care that there is some waiting to get an AWT.
To prevent AMP worker tasks exhaustion, and reduce the time reported in WorkMsgReceiveDelay, we recommend you use stronger throttle so there is less concurrency on the platform. That will lower the demand for AWTs.
If your were asking about the throttle delay queue increasing to 3 or 4 digit numbers, that is considered rather lengthy for a throttle delay queue. A lot of users will be waiting a long time for their queries to run. But no additional I/O or CPU is being used in that case either. The requests are just being held at the parsing engine until each throttles counter falls below its limit. It might be a good idea to review workload management setup if your throttle delay queues are often of that length.
Thanks, -Carrie
Geeta,
There are many different delay queues in the database. When you say "delayed sessions in the delay queue" that you say you can see in Viewpoint, I believe you are speaking about the throttle delay queue. The throttle delay queue is on the parsing engine and is delaying requests before they begin execution.
The throttle delay queue is entirely different from the ResUsageSPS metrics WorkMsgSendDelay and WorkMsgReceiveDelay. I am assuming that those are the two metrics you are referring to when you reference "send delays" and "receive delays".
WorkMsgSendDelay and WorkMsgReceiveDelay have nothing to do with requests that are delayed by a throttle. WorkMsgSendDelay and WorkMsgReceiveDelay represent the time in milliseconds that a work message was delayed in being sent from one vproc to another, such as from the PE to the AMP, or being received on a vproc. Those are milliseconds of wall-clock time that the work message was either waiting to be sent, or waiting to get an AWT once it arrives on the AMP.
When you ask about the "delay queue" becoming a 3 or 4 digit number, it is not clear if you are asking about the throttle delay queue, or the time in milliseconds that a work message was delayed in getting an AWT (WorkMsgReceiveDelay). In either case, the object being delayed (in the first case a request, in the second a work message that represents a step in a request), no CPU or I/O is being consumed during the waiting.
If you are asking if it is problem if WorkMsgSendDelay and WorkMsgReceiveDelay reports 3 or 4 digit numbers in ResUsageSPS, it is not necessarily a problem. However, it usually is an indication of running out of AMP worker tasks or being in flow control. It would be better to monitor MaxInuse and MailBoxDepth in the ResUsageSAWT table to understand the severity of AWT exhaustion. What WorkMsgReceiveDelay data is useful for is when you want to find out what workload is being impacted by a shortage of AWTs. The workloads with the higher number of milliseconds in that field in ResUsageSPS are the ones that are being impacted the most by AWT shortages. Whether or not that is a problem for you depends on how you interpret that in your environment. If it is low priority work you may not care that there is some waiting to get an AWT.
To prevent AMP worker tasks exhaustion, and reduce the time reported in WorkMsgReceiveDelay, we recommend you use stronger throttle so there is less concurrency on the platform. That will lower the demand for AWTs.
If your were asking about the throttle delay queue increasing to 3 or 4 digit numbers, that is considered rather lengthy for a throttle delay queue. A lot of users will be waiting a long time for their queries to run. But no additional I/O or CPU is being used in that case either. The requests are just being held at the parsing engine until each throttles counter falls below its limit. It might be a good idea to review workload management setup if your throttle delay queues are often of that length.
Thanks, -Carrie