Sun System Handbook - ISO 3.4 June 2011 Internal/Partner Edition | |||
|
|
Solution Type Technical Instruction Sure Solution 1001653.1 : Understanding Oracle Solaris Time Sharing(TS) Dispatch Tables for Low- and High-end Servers
PreviouslyPublishedAs 202249
Applies to:Sun Fire E4900 ServerSun Fire 6800 Server Sun Fire E6900 Server Sun SPARC Enterprise M4000 Server Sun SPARC Enterprise M5000 Server All Platforms GoalThe Oracle Solaris[TM] process scheduler uses certain default values for scheduling in the time-sharing class.The configuration is implemented as a simple lookup table and can be viewed using the command " dispadmin -c TS -g ". The default values usually only depend on the Oracle Solaris release used and are independent of a specific platform or hardware. There are however exceptions for the high-end servers (currently Sun Enterprise[TM] 10000, Sun Fire[TM] 12K/15K/E20K/E25K). The dispatch tables for these high-end systems have been modified to better support typical server applications (especially databases). SolutionThe general dispatch table is a good trade-off between long-running processes and short-running processes such as interactive use. The dispatch table of the high-end servers has been modified to have longer default time quantums for each priority. If several processes are competing for CPU resources (load higher than the number of available CPUs), the new high-end dispatch table will cause less process switching while each process will stay longer on the CPU. As a result, interactive use (or response time of similar short time processes) might get delayed in such overload situations as they have to wait for one of the long term processes to exceed the given time quantum.To illustrate the difference, here is an example of a system running Oracle Solaris 8:
% dispadmin -c TS -g
% dispadmin -c TS -g By default, processes will start at priority 59 and on normal machines will get 20ms time quantum on the CPU. If they exceed this CPU limit, they will be reduced in priority. If another process with higher priority is waiting for CPU resources, the current process will be taken off the CPU and the other waiting process will get the CPU. In the case of a high-end server system, such a switch might be delayed up to 340ms instead of the default 20ms, and interactive users might get a slower response as they have to wait for the other server processes to exceed their time quantum. Please note that such a situation only occurs if all CPUs are busy dealing with long-running and CPU-intensive processes. Additionally, interactive or short term processes will get started. If you are using one of the high-end servers in such a mixed mode (CPU-intensive, long-running processes together with interactive or short term processes in high load situations), then you might want to revert to the default dispatch table if faster response time for short term processes is needed. Keep in mind, though, that you already deal with a situation where all CPUs are overloaded. If you increase the number of process switches, this will delay the long-running processes. The special dispatch table for high-end servers was introduced in Oracle Solaris 2.6 and went through several design changes in later Oracle Solaris releases. As of Oracle Solaris 8 and later, the alternative dispatch table is now included in the normal TS_DPTBL kernel module. The kernel module will check if Solaris runs on a high-end server and automatically activate the alternative dispatch table. Activation of this high end dispatch table can be controlled via the variable ts_dispatch_extended in the file /etc/system.
The changes to the dispatch table are usually only helpful if your system is already overloaded and you want to have higher priority for the short term processes. You should consider adding more CPU resources or controlling your available resources using the Oracle Solaris Resource Manager (SRM) which has been integrated in Oracle Solaris 9 (and is available as a separate product for previous releases). @Internal Comments To find the extra code for Solaris 2.6: http://aggregate.eng/on297_dhpg/source/usr/src/uts/common/disp/ts_dptbl.c For Solaris 7 the changes are trivial (shell script) and for Solaris 8 (and later) you should check the regular ts_dptbl.c source plus the additions from usr/src/uts/sun4u/starcat/os/starcat.c and usr/src/uts/sun4u/starfire/os/starfire.c (which activate the new table). Some architectures may select the new table if the system is using Ultra Sparc III+ or newer CPUs. This was true for Daktari and Serengeti when the fix for Bug ID 6239229 Click Here was introduced in Solaris Nevada build 17, but after half a year this was removed as part of a fix for Bug ID 6291734 Click Here. See SCCS logs for usr/src/uts/sun4u/daktari/os/daktari.c and usr/src/uts/sun4u/serengeti/os/serengeti.c for the history of bug fixes. Currently Serengeti and Daktari use default dispatch table out of the box. None of the released Solaris versions have used the new/temporary default for Serengeti or Daktari (as this was only added and removed in the internal development releases). The new implementation in Solaris 8 was the result of PSARC 1999/434. Discussion is ongoing if/which additional new architectures should also have the "server dispatch table" on by default. This question needs to be answered for each new architecture. The dispatch table for high-end servers is also referenced in some of the tuning documents for databases. Users of the dispatch table with larger time quantums should know what they are doing and not be too surprised if the response time for interactive use increases if the machine is overloaded with database processes. Regarding OPL systems: usr/src/uts/sun4u/opl/os/opl.c now also uses the server dispatch table(integration of Bug ID 6476273 Click Here which uses the now somewhat incorrect summary that OPL should use the same dispatch table as serengeit/daktari as the selection there has changed). The OPL information will be added in the next update. In Oracle Solaris 2.6, special support for the Sun Enterprise 10000 was introduced. During installation on such a sun4u1 architecture, the package SUNWcar.u1 installs extra kernel modules in the directory /platform/sun4u1/kernel/sched/. Inside this directory you will find the modules TS and TS_DPTBL which will take precedence over the default modules in /kernel/sched/. If you want to disable the specific tables you can rename or delete the special modules, in which case the default modules will get used. Starting with Oracle Solaris 7, the high-end dispatch table is not a separate kernel module. A new init script has been developed which gets installed as /etc/init.d/tsquantum. This script will check if Oracle Solaris[TM] 7 is running on a Sun Enterprise 10000 and load the dispatch table from the ASCII file /usr/lib/class/TS/TSbigquanta. You can deactivate the special dispatch table by removing or deleting the /etc/rc2.d/S99tsquantum file. Attachments This solution has no attachment |
||||||||||||
|