How can I tell how much memory I need?
A: I've tried to answer this question a few times, but the real problem is that Solaris doesn't give you enough information on what memory is being used for. A few years ago a Sun systems engineer based in Adelaide, Australia, started looking for solutions to this problem. He came to work with me for a month in November 1995 and developed some new tools. In April 1997 we hired him to work full-time in our group, and now Richard McDougall is ready to share his knowledge with the world via a new white paper The Solaris Memory System -- Sizing Tools and Architecture (see Resources section), and a new tool set, the RMCmem package.
The RMCmem tools
The white paper contains details on how to obtain the tools. The package includes a kernel module that provides extra instrumentation, and is not a supported Sun product. As with any unsupported package, you should not depend upon it in a production environment. Bugs, patches, or interactions with other kernel modules could crash your system, and there is some additional data-collection overhead. Part of the package was integrated into Solaris 2.6, and we're using the tools as a proof-of-concept prototype to guide future enhancements to Solaris. An earlier collection of these tools was known as the RMCbunyip package -- the Bunyip is a legendary monster in Australia.
The four main uses of memory
Solaris is a virtual memory system. The total amount of memory that you can use is increased by adding swap space to the system. If you ever see "out of memory" messages, adding swap space is the usual fix. Performance of the system is very dependent on how much physical memory (RAM) you have. If you don't have enough RAM to run your workload, performance degrades rapidly. In this discussion I'm mainly concerned with RAM usage, and knowing how much is enough.
Physical memory usage can be classified into four groups:
- Kernel memory mapped into kernel address space
- Process memory is mapped into a process address space
- Filesystem cache memory that is not mapped into any address space
- Free memory that is not mapped into any address space
RMCmem includes a simple command to summarize this:
Total physical memory
The total physical memory can be seen using
prtconf. Memory is allocated in units called pages, and you can use the
pagesize command to see whether you have 4096 or 8192 bytes per page:
From an application you can call
sysconf(_SC_PHYS_PAGES) to find out how many pages of memory you have, and
getpagesize() to see the size. In some cases the result you get is less than the total -- as during boot, the first few megabytes are grabbed by the kernel, and what remains is made available to the system as pages (counted by the kernel as
Kernel memory is allocated to hold the initial kernel code at boot time, then grows dynamically as new device drivers and kernel modules are used. Kernel tables also grow dynamically, unlike some older versions of Unix. As you add hardware and processes to a system, the kernel will grow. In particular, to keep track of all the memory in a system, the kernel allocates a page table structure. If you have several gigabytes of RAM this table gets quite large. The dynamic kernel memory allocator grabs memory in large "slabs," then allocates smaller blocks more efficiently. This means that the kernel tends to grab a bit more memory than it's really using. If there is a severe memory shortage, the kernel unloads unused kernel modules and devices and frees unused slabs. The simplest summary of kernel memory usage comes from
sar. The old memory allocator architecture is still reflected in
sar's output format, which lists a pool of small allocations (under 512 bytes each), large allocations (512 bytes to a page), and oversize allocations (a page or more). The new allocator is more sophisticated and is best seen by running the
crash command as root and using the
kmastat option to list the individual memory pools:
Totaling up the small, large, and oversize allocations, the kernel has grabbed 12,083,200 bytes of memory and is actually using 10,186,028 at present.
Application process memory
Application processes consist of an address space divided into segments, where each segment maps either to a file, anonymous memory (the swap space), System V shared memory, or a memory mapped device. The mapped files include the code and initialized data for the command and all its shared libraries. Files that the process has accessed via the
mmap call may also be included, but not files that have been read and written in the normal manner. The segments can be viewed using
/usr/proc/bin/pmap on any system running Solaris 2.5 or later.
What is shown here is the base address and size of each segment, together with its mapping. Inode 108245 is the
cat command itself. The
cat command uses
mmap for its input file, and inode 226 matches the file being read.
What we really want to know, however, is the amount of RAM used by each segment. This is shown by the
pmem command in the RMCmem package in Solaris 2.5.1. The new kernel measurement used by this command was added to Solaris 2.6, where it can be seen using
Now we can see that the process address space size is 864 kilobytes; 846 kilobytes of that are currently resident in main memory, wherein 720 kilobytes are shared with other processes while 128 kilobytes are private. When this command started only the 128 kilobytes of private memory were taken from the free list.
If we now go through all the processes on the system, add up how much private memory they use, and also add in the shared memory for each mapped file, we'll know how much application memory is in use. This summary is shown by
prtmem as we saw in the beginning, and the detail is listed by the
memps command in RMCmem. Note that the X server maps over 100 megabytes of Creator3D framebuffer hardware address space in this example, and processes that run only in the kernel address space do not have any address space of their own.
Filesystem cache memory
This is the part of memory that is most confusing, as it is invisible. You can only tell it's there if you access the same file twice and it's quicker the second time. The RMCmem package adds kernel instrumentation that counts up all the pages for each cached file. The
memps -m command lists the files that are cached in order of the amount of memory they're consuming. One problem is that within the kernel the file is only known by its inode number and filesystem mount point. The directory pathname for the file may not be known. The RMCmem package tries to solve this problem by catching file names as files are opened (by interposing on the vnode open code) and making an inode-to-name lookup cache in the kernel. This cache size is limited (to 8192 entries by default), and the file may have been opened before the kernel module was loaded, so it can't always find the name. You see a mount point (in this case
/800008) and the inode number for that mount point:
To add up all the memory taken up by shared library files another command is provided by RMCmem:
Free memory is maintained so that when a new process starts up or an existing process needs to grow, the additional memory is immediately available. Just after boot, or if large processes have just exited, free memory can be quite large. As the filesystem cache grows, free memory settles down to a level set by the kernel variable
lotsfree. When free memory falls below
lotsfree, all the other memory in the system is scanned to find pages that have not been referenced recently. These pages are moved to the free list.
Graphical user interface tools
There is now a lot of new data available. To view it more easily and interactively, Richard wrote a Motif-based GUI tool. The
memtool program comes up with a list of the files that are in memory and also shows the pageins and pageouts that have occurred for each file in the last measurement interval.
|Example display of filesystem cache using memtool
There are three displays available. The second one shows process memory usage, and clicking on a process gives the detailed segment list as shown here for the X server.
|Example display of process memory usage using memtool
The third display is a matrix that combines the two views. It shows the processes across the screen and the files down the side, with each cell holding the amount of memory mapped from that file by that process.
|Example memtool process and file matrix display
So, finally, we can tell where all the memory is going. Richard's white paper contains a lot more information, including typical memory sizes for many common commands and daemons, and a full explanation of how the memory system works, and how to size memory configurations for desktop and server systems.
The white paper is at http://www.sun.com/sun-on-net/performance/vmsizing.pdf.
The tools can be obtained by sending e-mail to: email@example.com.
New book update
On another recurring subject, my new book is now in the final stages of the production process. It should become available sometime in April. It ended up being more than 600 pages long (the old book was about 250 pages). The title is Sun Performance and Tuning -- Java and the Internet, by Adrian Cockcroft and Richard Pettit, Sun Press/PTR Prentice Hall, ISBN 0-13-095249-4.
Resources and Related Links
Richard McDougall's The Solaris Memory System -- Sizing Tools and Architecture
Other Cockcroft columns at www.sun.com