AMP vprocs always run in parallel, but the way data rows or column values are striped across the disks affect the parallel operation of AMP step processing.
Unbalanced, or skewed, or spiked, disk loads can cause one or a few AMPs to be doing most of the I/Os. For example, when a numeric column allows zeros and/or nulls, the majority of rows might hash to the same AMP.
If your disk loads are poorly balanced, discuss with operations ways to correct the situation. For example:
- Perhaps queries or views against a column with zeros/nulls could use “WHERE NOT NULL” or “NOT= 0” qualifiers.
- If the cause is a NUPI, consider redefining the index, especially for a very large table, to achieve a higher percentage of uniqueness.
Common Skew Issues
| Issue | Cause | Results |
|---|---|---|
Same row hash value for an excessive number of rows
|
The table is skewed due to a highly nonunique primary index
(PI). As an estimate, more than 1000 occurrences/NUPI value begin to cause performance degradation problems. This figure is based on all the rows for the same NUPI value spilling over into more than five data blocks. |
|
| The data block size is set too low. See Managing Data Block Usage. Data block size should
not be a problem on systems using block-level compression
because the size should be set to the maximum.
|
||
| Some AMPs have many more rows of a table than do other AMPs. |
|
|