Archives of the TeradataForum

Message Posted: Fri, 03 Sep 2004 @ 17:21:48 GMT

	<Prev	Next>		<<First	<Prev	Next>	Last>>

Just a little more detail on flow control. It represents a higher stage of congestion than does being out of AMP worker tasks.

Each AMP has what is known as a flow control gate for sender messages and one for receiver messages. This flow control gate keeps track of messages for the component.

Once the queue of messages that are waiting to be serviced by an AWT grows to a certain length, new messages are no longer accepted on that AMP. The flow control gate will temporarily close and messages will be pushed back to their sender. The sender will then retry the message until it can be received.

For smaller configurations, the length of the queue is usually limited to 20 messages. For larger systems the threshold becomes the number of nodes in the configuration plus 5. For example, in a 40-node system an AMP will go into a flow control state if there is 45 or more messages queued waiting for an AWT.

By turning away newly arriving work, the AMP has a chance to work off the current queue. This also acts to keep the queue from using unacceptably large amounts of memory just holding messages. And because the rejection and acceptance of new work happens at the lowest level, the AMP, there are no layers to go through to get back to normal message delivery. The impact is kept local-only the AMP hit by an over-abundance of messages at that point in time throttles back temporarily.

If you find flow control conditions are more than an exception on your platform, and the condition lasts more than a few seconds, then you might consider throttling back the work that Teradata is being asked to do or trying to reschedule some of it to a less busy time (or, it goes without saying, increase h/w capacity). Flow control, as well as having a queue of messages waiting for AWTs, can have an impact on highly response-sensitive work.

Thanks, --Carrie

	<Prev	Next>		<<First	<Prev	Next>	Last>>