Timeshare Decay - Advanced SQL Engine - Teradata Workload Management

Teradata Vantageā„¢ - Workload Management User Guide

Product
Advanced SQL Engine
Teradata Workload Management
Release Number
17.10
Published
July 2021
Language
English (United States)
Last Update
2021-07-28
dita:mapPath
pzr1600284001549.ditamap
dita:ditavalPath
pzr1600284001549.ditaval
dita:id
B035-1197
lifecycle
previous
Product Category
Software
Teradata Vantage
Many customers use estimated processing time to prioritize shorter requests. To do this, customers usually define three workloads for each account, based on CPU usage:
  • Short
  • Medium
  • Long

Customers also create exceptions on the Short and Medium workloads so that longer-running requests move to a lower-priority workload.

Another way to prioritize shorter requests is to enable the Timeshare Decay option. This option decreases the resources available to longer-running requests. This option applies to all requests running in the Timeshare tier; it does not apply to workloads in the Tactical or SLG tiers. TIWM does not include exceptions, but DBAs can use the Timeshare Decay option to provide similar functions in demoting requests.

The Timeshare Decay works as follows:
  1. A request starts with the resource access rate assigned to it based on workload and workload management method (tier).
  2. TASM halves the resources available to the request on that node after the request consumes 10 seconds of CPU or 100 MB of I/O on that node.
  3. TASM again halves the resources available to the request on that node after the request consumes 200 seconds of CPU or 10,000 MB of I/O on that node. This access rate remains constant until the request ends.
TASM performs timeshare decay on each node independently. This means that a request can be running at different decay levels on different nodes.
Before deciding to use Timeshare Decay, consider these tradeoffs:
  • All Timeshare tier workloads are affected. TASM cannot target decay to specific workloads.
  • The thresholds that trigger decay are the same for all workloads in all access levels. Top is treated the same as Low.
  • If many Low requests experience decay, they may receive so few resources that they hold locks and AMP worker tasks for unreasonably long times.
  • If most of the requests in Timeshare experience automatic decay, most of the requests have the same relative priority to each other as they did before the decay was applied.
Tip: For systems with TASM, workload exceptions provide more robust and tunable options to achieve the same goal as Timeshare Decay by using the change workload action. For TASM systems, workload exceptions are more predictable and measurable. Timeshare Decay is appropriate for TIWM systems, which do not have workload exceptions.

If you enable query logging, the level of decay for a request is logged in the CPUDecayLevel and IODecayLevel fields of DBQLogTbl.