Default Limit and Reserve Values

Preparing to Move from SLES 10 to SLES 11

Published
January 2016
Language
English (United States)
Last Update
2018-05-04
dita:mapPath
bdv1467307738050.ditamap
dita:ditavalPath
ft:empty
dita:id
yiu1467244923010
Product Category
Hardware
Software

Regardless of whether you use the Pre-Migration Tool, the workload-migration process that occurs as part of upgrading to SLES 11 specifies system-wide limit and reserve values for the Always planned environment, as shown in the following table.

Parameter Value
CPU Limit Existing value in "PsfGlobalOpenvValues" of base state (Always PlannedEnv) otherwise 100
I/O Limit 100
Reserved AWTs Existing value in "PsfGlobalOpenvValues" of base state (Always PlannedEnv) otherwise 0
Max AWTs for new work Existing value in "PsfGlobalOpenvValues" of base state (Always PlannedEnv) otherwise 80
Regardless of workload-management licensing in SLES 11, you can use the Workload Designer portlet in Viewpoint to change reserve values as necessary to meet priority-scheduling goals. With TASM licensing, you can change both reserve and limit values.
When determining values for CPU and I/O limits, administrators of TASM-licensed systems should consider the following:
  • In SLES 11, operating system utilities and work running on nodes external to those housing the Teradata Database are not subject to the CPU limit. However, non-database demands as well as resources that may be required for tuning or growth purposes should be taken into account when establishing CPU limit. By adjusting the limit downward from 100%, you can provide adequate resources for all work while reserving resources for any necessary refinements.
  • All database activities that were exempt from the CPU limit in SLES 10, including rollbacks when running at the default DBS control settings and work running in the System performance group, are subject to the limit in SLES 11 by default.
  • Unlike in SLES 10, tactical workloads in SLES 11 are subject to the CPU limit. However, in SLES 11, such workloads are allocated the highest priority by default. Thus, there is no need to limit CPU at the system level to insulate tactical work from competition for CPU resources.
  • To protect against a perceptible increase in average elapsed time for completing highly critical work or work associated with short service level agreements, CPU limit be should be set no lower than 63%.
  • Only physical I/Os that actually involve reading or writing from disk are subject to I/O limit. The cost of each such I/O is determined after the I/O request arrives, based on hardware specifications for the device. This cost is then subtracted from the total allowable bandwidth for the device as mandated by the established I/O limit value. A given device’s available I/O bandwidth can be ascertained at any point in time based on the known maximum bandwidth of the device and the cost of the I/Os already performed. When I/O limit is reached within a given enforcement interval, I/O activity on the device ceases for the remainder of that interval.
Although administrators of TASM-licensed systems can set disparate values for CPU and I/O limits, it is strongly recommended that you refrain from doing so. If default migration processing results in such a disparity, use the Workload Designer portlet in Teradata Viewpoint to adjust the I/O limit value to match the CPU limit value. Establish disparate values for these parameters only at the recommendation of authorized Teradata support personnel.

For more information, see Teradata Viewpoint User Guide. Additional information pertinent to CPU and I/O limits specifically can be found in the following Orange Book: Workload Management Capacity on Demand, Teradata Database 14.10 and Linux SLES11, 541–0010245–A02.