Click on our Sponsors to help Support SunWorld
Performance Q & A by Adrian Cockcroft

What's new in Solaris 7?

Highlights of the new performance-related features and their impact on applications

November  1998
[Next story]
[Table of Contents]
Subscribe to SunWorld, it's free!

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
Q: Sun just announced its major Solaris upgrade. What are the main elements that will affect performance and capacity planning?

A: 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 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 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 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

Bandwidth Manager is described in more detail at

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.

Click on our Sponsors to help Support SunWorld


Resources mentioned in this column Additional resources Other Cockcroft columns at

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

What did you think of this article?
-Very worth reading
-Worth reading
-Not worth reading
-Too long
-Just right
-Too short
-Too technical
-Just right
-Not technical enough

[Table of Contents]
Subscribe to SunWorld, it's free!
[Next story]
Sun's Site

[(c) Copyright  Web Publishing Inc., and IDG Communication company]

If you have technical problems with this magazine, contact

Last modified: