Most of the resources of a system are consumed by requests running in workloads that were defined by the administrator, workloads that are managing user-initiated work. However, some small percentage of resources, mostly CPU, is utilized by what we call internal workloads.This posting will help you understand what kinds of activities are running in those internal workloads, and some of the reasons why utilization there can and will fluctuate.
The Priority Scheduler Hierarchy
The SLES 11 Priority Scheduler is structured following the SLES operating system hierarchy of control groups. A control group named Tdat sits at the top of the Teradata Database workloads. Immediately under Tdat and before the virtual partition level is a level for special control groups supporting internal database activities. Some of these activities happen as a direct result of a user requests, such as AMP worker tasks management. But they are generally system-level functions that need to happen fast and at a very high priority.
Dflt and System
Both Dflt and System (workloads 255 and 254) consist of a single workload as shown in the graphic above. Some of the activities that take place in those internal workloads include:
There is another location in the priority hierarchy where internal work is performed. At the virtual partition level is a virtual partition named “InternalVP”. You cannot see this virtual partition from Viewpoint Workload Designer and you cannot monitor its usage from Viewpoint Workload Monitor, but it is active supporting other less critical internal activities that keep the database healthy.
The Internal Virtual Partition
Internal VP: The Internal VP supports internal database tasks and regular background tasks that are less critical than those running in System and Dflt workloads, but is still important enough to need to get done quickly. InternalVP only contains a Timeshare tier, with a Top, High, Medium and Low workload, numbered as shown above (workloads 250 to 253). To give you an idea of the kinds of things that run there, here some of the things that the two lower priority of those four workloads are doing:
Internal Workload Usage Variance
All of the internal workloads combined generally use a low percent of platform CPU, a few percentage points. However, there are times when the combined usage in InternalVP can reach 5% or greater. Some of the situations when you can expect these workloads to display somewhat higher CPU usage include:
Teradata Database relies heavily on background tasks to speed the efficiency of query work and to perform file system clean up. Many of these background tasks rely partially or completely on these internal workloads. For example, when temperature-based block level compression is activated, TVS keeps track of cylinder temperature, and unobtrusively moves cylinders in the background. Although much of that effort runs in the background at a low priority, part of this activity can contribute to an uptick in CPU usage in some of these internal workloads.
You do not have to monitor usage in these internal workloads, or even give much thought to them. And what they do and why will always be a bit mysterious to people such as you and me. Keep in mind that everything running under the surface in the Teradata Database is self-managing, highly optimized, and is happening for a very good reason. But if you are curious, and observe an uptick in CPU usage in any of these workloads, try to correlate it with activities on your platform that are taking place at that time that these workloads may be helping out.
Internal workloads perform essential services to the database, that keep the database running efficiently and that help sustain high throughput. Many internal tasks related to monitoring, the file system, recovery and reliability, and accounting run in these workloads and will require small levels of CPU. The more activity on the database, the greater the need for these activities and their contribution. Certain types of user activity my drive greater requirements from the internal workloads.
One final point, usage in these internal workloads will tend to be more smooth if you are on a current release of database software. Improved approaches for keeping the database healthy in non-intrusive ways are always evolving.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.