What Priority Scheduler Internal Workloads Actually Do

Blog
The best minds from Teradata, our partners, and customers blog about whatever takes their fancy.
Teradata Employee

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.

  • User is an anchor for all the virtual partitions and workloads that represent work being done within the Teradata Database. No CPU is consumed within the User control group
  • Dflt is highly-critical internal database work, usually very short
  • System is considered of the highest importance and is given a comparatively high share of resources, as it supports PDE daemons and critical internal processes.

Internal_WDs.jpg

 

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:

 

  • Dflt (WD = 254): Supports all internal tasks running at the database priority of TaskPrioMaximum, such as AMP worker task management, certain file system tasks, purge tasks, some accounting tasks.

 

  • System (WD = 255): Most of the activity in this internal workload is PDE daemons. Daemons are necessary in a multi-tasking operating system. These are background tasks not associated with any user request, but that provide internal services and run scheduled internal tasks, including many critical database housekeeping tasks.

 

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:

 

  • 250 (LowIntTS workload) supports special database tasks that are not associated with a user request, such as deadlock detection and space accounting.

 

  • 251 (DefaultlntTS workload) manages TBBLC and other compression-related background tasks, lctmain tasks which play a role in load utilities, some DBQL-related tasks and other accounting tasks.

 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:

  • Times when the system is being fully utilized
  • When there is a lot of updating taking place, such as during an intensive batch load window
  • In the presence of congestion and/or flow control
  • When block-level compression is turned on
  • If frequent mini-cylpacks are taking place
  • In situations where there are frequent aborts and rollbacks

 

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.

 

Conclusion

 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.