If I am understanding you correctly, you are saying is that by the time you get an alert from Teradata Manager that your AMP worker task availability counts have reached some low threshold on at least one AMP (such as 5 in your case) that the actual AWT availability has gone down to 2. That could happen because Teradata Manager alert is triggered by a point-in-time event (only 5 AWTs remaining on one AMP). AWT in-use counts can change very quickly, so within less than 1 second from when that threshold was met there could be more AWTs being used. Teradata Manager only does an alert when the threshold is reached, it does not stop the available AWTs from going down even more.
CPU usage is usually higher when a higher number of AMP worker tasks are being used, because more work is active, but that is no always the case. The only way to know is to look at the CPU monitoring tools.
You are correct that skewed processing can be responsible for higher AWT in-use counts on some AMPs. That is often the case when a single AMP has more work to do on one query step. The skewed AMP will hold AWTs for the skewed query longer than other AMPs, and because of the higher demand for resources, will be slower to complete the non-skewed work, so that work may also holds its AWTs longer on that AMP. higher-than-average AWT in-use count. DBQL can be helpful in identifying which query was responsible for skewed IO or CPU consumption.
↧