What's new in Solaris 7?
Highlights of the new performance-related features and their impact on applications
November 1998
![[Next story]](/sunworldonline/icons/tb-next.gif){kind=icon}
![[Table of Contents]](/sunworldonline/icons/tb-toc.gif){kind=icon}
![[Search]](/sunworldonline/icons/tb-search.gif){kind=icon}
|
|
What's new in Solaris 7?Highlights of the new performance-related features and their impact on applications |
November 1998
|
Adrian discusses the changes in Solaris 7 that affect performance and portability. He also introduces a couple of new resource management products for Solaris 2.6, the Solaris Resource Manager 1.0, and Bandwidth Manager 1.5. (1,600 words)
 Mail this article to a friend |
:
Sun just announced its major Solaris upgrade. What are the main elements
that will affect performance and capacity planning?
:
There are two distinct announcements I'd like to discuss. One is
Solaris 7 and its new features. The other is a pair of new resource
management products that run on Solaris 2.6. You can find further
discussion of Solaris 7 in Jim Mauro's Inside Solaris
column this month and at http://www.sun.com/solaris.
I talked about fixes to the calculation of wait I/O in Solaris 7 in my column last
month. (See Resources below.)
Let's start with the name change. We took the 2. away, and Solaris 7
should never be written as 7.0; there is no subversioning. The key
thing to realize is that this is primarily a branding and marketing
name change. The only places the operating system has changed are in
the /etc./release file and in some directory names on install server
boot images. The uname -a command still returns SunOS 5.7,
so all your application install scripts will continue to work as they have been.
New Solaris 7 features
From a performance point of view, the ability to run 64-bit
applications on Solaris 7 has two main benefits. One is that much
larger problems can be solved efficiently using a bigger process
address space; the other is that integer arithmetic computations get
to use 64-bit registers and operations. Overall, programs get
slightly larger due to larger pointer values in code and data
structures. This in turn means that CPU caches are a little less
likely to have enough cache lines, and a slight slowdown might occur in
programs that could run just as well in a 32-bit
environment.
The industry benchmark result that benefits most is the TPC-C database benchmark. It is overtuned and unrepresentative, but high-end results require a shared memory segment for the database that is more than 4 gigabytes (GB) in size. Sun has now announced an E6500-based record result using Solaris 7 and Sybase. You can get more information from http://www.tpc.org. Full-disclosure reports are published there after a week or two of review.
The directory name lookup cache has been upgraded to be dynamically allocated on demand, rather than preallocated to the full size in advance. Each cache entry is now variably sized up to the full pathname component length of 255 characters. The old limit of 30 characters is gone, along with the measure reported by vmstat -s called toolong, as it would always be 0. Overall average sizes were found to be much smaller than 30 characters in most cases, and a net reduction in memory used was combined with some other performance improvements for the new version.
Priority paging tunable
There is an improved paging algorithm in Solaris 7 that has also
been backported to kernel patch 105181-09 for Solaris 2.6. A Solaris
2.5.1 backport was not yet issued at the time of this writing. By
default the new behavior is turned off, so it is important to enable
the fix on systems that are paging noticeably.
It makes switching between windows on desktop systems snappier, and it's a big help for databases running on the filesystem and for jobs that read large files into memory. If your system pages heavily, speed increases of several hundred percent have been seen for compute-intensive jobs with a large dataset. If you have less than 64 megabytes (MB) of memory, the change might be counterproductive, but will still help in most cases.
This fix was designed by my colleague Richard McDougall, memory guru and author of the memtool package described in my March 1998 column (See Resources below.) A full description of the fix written by Richard is available at http://www.sun.com/sun-on-net/performance/priority_paging.html. It is enabled on both Solaris 2.6 and Solaris 7 by adding the line: set priority_paging=1 to /etc/system.
If you find that your system repeatedly slows down with priority paging enabled, please let us know, as we plan to turn it on by default in a future release if we don't find any negative implications.
|
|
|
|
|
Portability and impact of Solaris 7 changes on applications
Applications that work on Solaris 2.6 "just work" on Solaris 7. I've
been running Solaris 7 on my own desktop machine for six months
without experiencing any problems in the regular applications I
use. The only problems I've seen are with code that looks inside the
kernel (like performance tools) and with the requirement for 64-bit
device drivers and kernel modules when running in 64-bit mode.
The SE toolkit and Richard McDougall's memtool package have to be extended to handle the new features of Solaris 7. Richard wrote a short whitepaper, "Porting Performance Tools to 64-bit Solaris" that I have made available. While Richard McDougall works at Sun and has already ported memtool to Solaris 7, Rich Pettit now works outside Sun and has only just started to port the SE toolkit to Solaris 7.
In the meantime, the current SE3.0 toolkit will work (for the most part) if it's tricked into using the Solaris 2.6 binary, as follows:
# cd /opt/RICHPse/bin # ln se.sparc.5.6 se.sparc.5.7
Each script you run will first print a warning message, but will then probably run fine. When run as a regular user, most SE scripts will work because the kstat interface hasn't changed, even with a 64-bit kernel. However, some SE scripts run as root will attempt to use the kvm interface for direct access to kernel variables.
With a 32-bit kernel these scripts still work. But with a 64-bit kernel, it isn't possible to open /dev/kvm from a 32-bit application, so they will fail immediately. Performance tool data collectors are likely to break for this reason.
New resource management products
Many performance problems cannot be fixed by tuning a system or
reconfiguring it because the workload consumes too many resources.
The traditional solution is to upgrade the system so that it always
has plenty of headroom to cope with peaks. The alternative is to
control the workloads so that the most important work has priority
over less important work and users get their fair share of the
resources. This becomes increasingly important when several smaller
systems are replaced with one large system running a consolidated
set of workloads.
Sun now has two ways to control resources for Solaris 2.6. The Solaris Resource Manager product, SRM 1.0, primarily controls CPU usage on a per-user basis, and the Bandwidth Manager 1.5 product controls the usage of network bandwidth by applications. Both tools also generate accounting information so you can determine who uses the most resources.
These are extremely important products for Sun, and we expect them to be used at all levels in the server product line. On a small workgroup server, you probably have a mixture of applications and workloads, but with only one to four CPUs it's hard to use processor sets to separate the work. SRM 1.0 allows finegrain resource control even on a uniprocessor system and can ensure critical services continue to respond quickly even at times of peak activity. Bandwidth Manager 1.5 lets you give priority to a certain protocol, system, or domain so that other network traffic is prevented from interfering with your important services. On a larger system, you can use these tools to implement mainframe-like operations management regimes.
At present, the two tools operate quite separately. In the future they will become more integrated, and Solaris will be extended so that additional resources such as RAM usage per process can be controlled.
There are a few implications for performance management tools. The main one is that any tool that attempts to use predictive models for capacity planning will need to be extended to take share policies into account. Without this extra information, predictions will be based on false assumptions and will be wildly inaccurate. Secondly, systems running SRM 1.0 can safely be used at much higher CPU utilization levels, and alarm rule thresholds will need to be changed to suit the new operating behavior.
Solaris Resource Manager 1.0 is described in detail at http://www.sun.com/solaris/ds/ds-resourcemgr
Bandwidth Manager is described in more detail at http://www.sun.com/solaris/ds/ds-bandwidthmgr
Wrap up
Solaris 7 adds a lot of very useful features while remaining extremely compatible with existing software. Brian Wong, Richard McDougall, and I have worked for the past three years on making SRM 1.0 a reality, integrating it with Bandwidth Manager, and helping to define both products' direction. We encourage you to evaluate them and give us feedback on your priorities for future developments in resource management.
|
|
Resources
About the author
Adrian Cockcroft joined Sun Microsystems in 1988,
and currently works as a performance specialist for the server division
of Sun. He wrote Sun Performance and Tuning: SPARC and Solaris and Sun Performance and Tuning -- Java and the Internet, both published by Sun Microsystems Press Books.
Reach Adrian at adrian.cockcroft@sunworld.com.
|
|
|
|
![[(c) Copyright Web Publishing Inc., and IDG Communication company]](/sunworldonline/icons/b-copyright98.gif){kind=icon}
If you have technical problems with this magazine, contact webmaster@sunworld.com
URL: http://www.sunworld.com/swol-11-1998/swol-11-perf.html
Last modified: