1.1. Key Features of Solaris 10, Solaris 9, and Solaris 8 This section briefly summarizes the key features of the Solaris releases covered in this edition of Solaris™ Internals. It is not a complete or comprehensive list of every new feature. A detailed and complete listing of new features can be found in the What's New document, which is generated for each major Solaris release, as well as each update release. What's New documents are available publicly on http://docs.sun.com. Remember, each release of Solaris is a proper superset of the previous release; thus, features found in Solaris 8 roll up into Solaris 9, and of course Solaris 10 incorporates features from Solaris 8 and 9. A feature initially introduced in an earlier release may be enhanced in a subsequent release. Examples here include UFS logging (introduced in Solaris 7, improved over time in Solaris 8 and Solaris 9), and Dynamic Intimate Shared Memory (DISM, introduced in Solaris 8 and improved in Solaris 9 and 10). The notable exception to the inheritance rule is hardware support. Support for older hardware products may be dropped from a given Solaris release. For example, Solaris 10 does not support 32-bit SPARC processors or the UltraSPARC I processor (which was released in 1995). Solaris 10 is a 64-bit-only release for SPARC systems and will run on SPARC systems using UltraSPARC II, UltraSPARC III, and UltraSPARC IV processors, as well as on any new SPARC-based processors and products introduced from this point forward and through the life cycle of the release. Of course, 32-bit SPARC programs and applications are fully supported and work just fine on the 64-bit Solaris 10 kernel. Solaris 10 also supports systems based on 32-bit Intel x86 and 64-bit AMD Opteron technology. 1.1.1. Solaris 10 The list of new technologies integrated into Solaris 10 represents some of the most innovative work done in a volume production operating system. Predictive self-healing. The term predictive self-healing describes the benefits derived from the integration of the Solaris Fault Manager and Solaris Service Manager technologies. Predictive self-healing maximizes the availability of a Solaris system and the services it provides when hardware and software faults occur. Facilities for event detection, isolation, and dynamic deactivation of faulty components have been developed, along with improved messaging and services management. Service Management Framework (SMF). SMF affords a unified model in Solaris for the management and administration of services. A service is a program or set of programs that are managed by the system. These may be traditional services, such as remote login or file transfer (ftp), data services (NFS, database), or custom application services. The traditional method of managing these services is through the use of startup scripts and state/configuration information, typically in the form of an /etc file. SMF provides a set of commands, utilities, and documentation that facilitate the starting, stopping, and restarting of services, as well as defining service dependencies. The SMF framework is integrated with the predictive self-healing fault management facility described above, such that fault and error events specific to a service can be monitored and managed in a consistent and robust fashion. Solaris Fault Manager. This new software architecture for fault management incorporates several software components, including an event protocol for sending and recording error and fault information, a fault diagnosis engine, and a new set of programming interfaces that improve diagnosis, isolation, recovery, and dynamic deactivation of faulty hardware. A fault-centric software model correlates error reports into a binary telemetry flow (defined by the event protocol) and dispatches the telemetry stream to the appropriate diagnosis engine. Software can then diagnose the fault and generate specific information about the fault for use by systems maintenance personnel. If possible, corrective action (for example, offlining a faulty processor) is automatically taken. Solaris Zones. Zones is a software partitioning technology that enables the creation and management of multiple virtualized operating system execution environments within a single instance of the Solaris kernel. Each zone (virtualized environment) appears as a system to the processes, users, and administrators within the zone and is isolated from other zones running within the same kernel instance. The isolation provides security, since processes running in one zone are not visible to processes running in other zones in the same kernel instance. The only exception to this is the global zone, which is the primary zone that represents the Solaris kernel instance. All processes running in all zones in a kernel instance are visible to the global zone. Zones also provide a resource management container, such that zones created to run specific applications (Web server, database server, etc.) can be configured to use a subset of the hardware resources available on the system. See the System Administration Guide: Solaris Containers, Resource Management and Solaris Zones for information on creating, managing, and using Solaris Zones. Dynamic resource pools (DRP). Resource pools were introduced in Solaris 9. They provide a persistent configuration mechanism for assigning one or more processors to a specific application or set of applications. Additionally, resource pools allow for establishing a default scheduling class, such as the fair share or fixed-priority classes, for applications started within a resource pool. In Solaris 10, a new facility dynamically adjusts the assigned pool resources according to utilization, load, and properties. A new daemon, poold, is always active when DRPs are configured; it monitors system statistics, correlates statistics to pool configuration properties, and makes dynamic adjustments as needed. For example, if resource pool A is configured to run at a maximum of 80 percent utilization, and it exceeds that threshold for a sustained period, poold may assign additional CPU resources from another pool that is underutilized. All changes made by poold are logged, and the DRP framework provides a rich set of property definitions that include various constraints and objectives for the resource pools. See the System Administration Guide: Solaris Containers, Resource Management and Solaris Zones for information on creating, managing, and using dynamic resource pools. Physical memory control. With the project framework introduced in Solaris 9, limiting the amount of physical memory a process can use at any point is now possible. A resource-capping daemon, rcapd, was introduced in Solaris 10; it monitors the physical memory use of running processes at regular intervals and enforces physical memory caps if a process exceeds its configured limit. With rcapd, processes that consume more memory than allowed will effectively page against themselves and not consume additional physical memory at the expense of other processes running on the system. See the System Administration Guide: Solaris Containers, Resource Management and Solaris Zones for information on configuring memory resource caps, and monitoring memory usage. Dynamic tracing facility (DTrace). A comprehensive dynamic tracing facility that dynamically inserts probes into applications, user processes, and the Solaris kernel. To use DTrace, you program the probes to fire; when fired, each probe collects data at specified points in the execution path and makes that data available to you. DTrace probes are analogous to software sensorsimagine having thousands of programmable sensors that you can turn on and off dynamically, enabling you to record data throughout the entire execution path of your application or workload, from user-level processes through the entire kernel. DTrace provides all the information you need to understand system behavior, to analyze performance problems, to research areas for improved performance and efficiency in your application, and to uncover and root-cause aberrant behavior on your systems. A new utility, dtrace(1M), can be used from the command line to enable probes and collect data. Additionally, a new scripting language, called D, allows DTrace to be used by invocation of D language scripts, thus empowering users, administrators, developers, and performance analysts to collect, refine, and reuse scripts for system behavior and performance diagnosis. DTrace has been designed from the ground-up for use in critical production environments. DTrace is safe, having been implemented with rigorous security and error checking. When no DTrace probes are enabled, DTrace has a zero probe effect: It is just as if DTrace were not there. This is because DTrace instrumentation is dynamically inserted into the running system when a probe is enabled. DTrace literally inserts instructions in the appropriate location in the code path for a given probe (typically, the entry and return points of a function), then restores the instruction stream to its original state when the probe is disabled. This means that no DTrace code exists in the instruction stream at all when no probes are enabled. The actual probe effect of DTrace is commensurate with the number of probes enabled: Enabling a few probes will likely not induce a noticeable probe effect, whereas enabling thousands of probes on a busy system will likely induce some level of performance regression, but system integrity (availability and data integrity) is never at risk. DTrace is used extensively throughout this text to illustrate kernel behavior and code flow. See the Solaris™TM Performance and Tools for information on using DTrace. Process rights management. Traditionally, superuser (root) privileges are required for performing specific tasks and using some features. However, providing superuser access to the user community at large imposes security risks, as well as threatening overall system integrity and availability. A simple mistake by a user running as root can have catastrophic consequences (for example, typing "rm -r *" in the root directory). Process rights management defines a set of privileges that can be assigned to specific users or roles or that can be enabled systemwide. A privilege is a bound and well-defined right to allow a process to perform a specific operation. Examples include these operations: using DTrace, changing file ownership, using high-resolution timers, setting processes to higher-priority levels, and using the real-time scheduling class. See the privileges(5) and ppriv(1) man pages for additional information. TCP/IP performance. A significant amount of engineering went into improving TCP/IP performance in Solaris 10, with an emphasis on network throughput (data rate, typically expressed as number-of-bits or number-of-bytes per second), connection setup and teardown, first-byte latency, connection and CPU scalability (scale-up of the number of connections with more available CPUs), and efficiency (amount of CPU required to drive the network load). Several changes were implemented, including increased performance and efficiency of the code path by removal of the STREAMS infrastructure surrounding the TCP and IP protocol layers, implementation of a worker thread model to handle higher incoming packet rates, and improved use of hardware caches through improved instruction and data locality. x64 architecture support. Support for Intel x86 processors has been part of Solaris since Solaris 2.1. With the addition of servers based on the AMD Opteron processor added to Sun's hardware product, the same kind of support for the AMD64 architecture was a priority engineering effort during the development of Solaris 10. In addition to the basic porting work, significant effort went into optimization, tuning, and native support for a 64-bit kernel on Opteron processors. Solaris 10 supports both 32-bit Intel x86 processors and 32-bit and 64-bit Opteron processors. Of course, support for multiprocessor Opteron processors, with the exceptional scalability of Solaris OS is now available on both SPARC and AMD64 platforms.
This list is by no means a complete list of all the new features in Solaris 10. For a complete listing, see What's New In Solaris 10 at: http://docs.sun.com/app/docs/doc/817-0547 1.1.2. Solaris 9 Solaris 9 offers several new kernel features that widen the gap between Solaris and other commercial operating systems; these features include, memory performance enhancements, a new set of resource controls and facilities, and new scheduling classes. Multiple page size support (MPSS). Memory allocation is done in units called pages, which have a default size of 8 Kbytes. However, UltraSPARC hardware supports larger page sizesup to 4 Mbytes. The MPSS set of command-line interfaces can be used to define larger page sizes for applications. The use of larger pages can provide substantial performance improvements for applications that require large physical memory allocations. Memory placement optimization (MPO) [Solaris 9 9/02]. Applications on Sun's high-end servers can benefit from allocation of physical memory pages in memory banks closest to the processors on which the application threads execute. This proximity of the executing threads to the memory they reference reduces latency on memory operations, thereby improving performance. MPO is tightly integrated into the Solaris dispatcher and memory allocation kernel code base, and it attempts to maintain proximity for physical memory allocations and the processors executing application threads. Dynamic Intimate Shared Memory (DISM). Intimate Shared Memory (ISM) was introduced in Solaris 2.6; it optimizes System V Shared Memory by allocating large memory pages for the shared segment, locking the pages in memory, and sharing low-level page translation information with all processes attaching to the shared memory segment. DISM dynamically resizes a shared segment, enabling use of dynamically added memory (using Sun's Dynamic Reconfiguration feature), and resizes database caches (implemented with System V shared memory segments) without the need to stop and restart the database instance. The original implementation of DISM (released in Solaris 8) did not include support for large pages. Solaris 9 9/02 adds large pages for DISM memory segments. Resource Manager (RM). Solaris 9 integrates resource management facilities, including resource pools for partitioning available hardware resources and the projects and tasks workload identifiers. Monitoring capabilities are integrated into bundled Solaris utilities (prstat(1M)), and the accounting subsystem is enhanced to provide extended accounting information based on workload identifiers and resource use. Fair Share (FSS) and Fixed Priority (FX) scheduling classes. In addition to the traditional Timeshare (TS), Real Time (RT), and Interactive (IA) scheduling classes, Solaris 9 adds the Fair Share (FSS) and Fixed Priority (FX) scheduling classes. The FSS class completely replaces the previous SHR class (Solaris Resource Manager 1.X); it allocates processor time to kernel threads based on user-defined allocations of shares of available processor resources. The FX class adds fixed-priority scheduling, by which the priority of threads in the FX class are not changed by the kernel during the thread's lifetime. The FSS class is an integral component of the Resource Manager facility, using resource pools to manage share allocation. UNIX file system (UFS) enhancements. UFS, the default file system in Solaris OS, improved performance in the areas of logging and direct I/O read/write concurrency. Solaris Volume Manager (SVM). Integrated into Solaris 9, SVM enables the creation of RAID 0, RAID 1, RAID 10, and RAID 5 storage volumes. Soft-partition support is also included, breaking the 7 partitions-per-volume barrier. Threads library. The threads library, libthread.so, boasts substantial performance improvements, and it transitions to a single-level threads model as default behavior for multithreaded applications.
1.1.3. Solaris 8 Solaris 8, first released in February 2000, contained a rich set of new features and underwent a series of continued improvements and enhancements over eight update releases. Internet Protocol Version 6 (IPv6). IPv6 extends IP addressing from 32 bits to 128 bits, resulting in a huge increase in the number of configurable nodes and networks. Other enhancements include a simplified IP header model, quality-of-service capabilities, and support for added authentication and privacy functionality. Solaris 8 allows configuration of a network interface card (NIC) with both an IPv4 and IPv6 address, and it supports network services, such as NIS and NFS, over IPv6. IP Security Protocol for IPv4 (IPsec). IPsec is a security protocol standard that secures data at the IP layer through encryption. Native Lightweight Directory Access Protocol (LDAP). LDAP support is integrated, so system administrators can easily adapt Solaris 8 systems into their LDAP environments or transition existing naming services to LDAP. Core file management. A new command, coreadm(1M), empowers system administrators to configure a target directory for core files generated by user processes, as well as to define the naming convention used for the core files. Role-Based Access Controls (RBAC). With RBACs, system administrators can provide limited system administration capabilities to non-root users. Execution profiles and roles are defined through configuration files, along with specific authorizations enabling the execution of tasks that otherwise require superuser (root) privileges. Alternate threads library. A new thread model replaces the original Solaris multilevel implementation with a 1-to-1, single-level thread model. This new model is made available in Solaris 8 through an alternative threads library, libthread.so, located in /usr/lib/lwp. (Note: This model became the default in Solaris 9.) Dynamic Intimate Shared Memory (DISM). Enhanced as described in the previous section, DISM was first introduced in Solaris 8. UNIX file system (UFS). UFS performance is improved in the areas of direct I/O, logging, concurrent direct I/O, and file system creation. Added features generate snapshots, and a new mount option defers access time updates. Modular debugger. A new kernel debugging facility, mdb, furnishes a rich set of utilities for examining kernel core files and a running system, as well as a development framework for building and integrating additional utilities (known as d commands) into the debugger. Note the mdb(1) 'd' commands are not to be confused with the DTrace 'D' scripting language. Tools and utilities. Some /proc tools are enhanced to work on core files. A new command, prstat(1), examines running processes. The apptrace(1) tool traces library-level application calls. The new pgrep(1) command gets process IDs, based on process names; the new pkill(1) command sends signals from the command line. truss(1) now traces user-level function calls. Hardware statistics utilities. New utilities let you look at system performance with hardware-maintained counters. The cpustat(1M) command reads processor hardware counters that provide observability into cache hit rates, instructions per clock cycle, and other platform-specific statistics. cputrack(1) provides a similar set of data access as that provided by the cpustat(1M) command but has additional semantics for focusing on a specific process or group of processes. The busstat(1M) command lets you access statistics from the hardware counters maintained in the main system bus or interconnect. Arbitrary resolution interval timers. A new kernel facility, called cyclics, provides fine-grained arbitrary resolution interval timers. Previously, timer granularity was bound by the kernel clock interrupt mechanism. In Solaris 8 (and beyond) applications using interval timers can now program their timers to fire at arbitrary intervals and can achieve nanosecond granularity (the actual attainable granularity is hardware-dependent).
|
