Document ID: 1901 SYNOPSIS: Why you get less and less swap space without increasing process sizes DETAIL DESCRIPTION: As time goes by we have noticed that we seem to have less and less swap space available. At first we assumed that we had a hungry process but checking process sizes with ps(1) reveals that none of our processes are growing in size. What's happening? SOLUTION SUMMARY: This can be caused by two things:- 1) By default your /tmp filesystem is mounted on the swap device, and the more things you put into /tmp, the less swap you have left. We make use of the swap device in this manner to provide you with an efficient temporary filesystem. Unlike RAM disks the tmpfs can grow and shrink therefore giving you the advantage of a fast RAM based filesystem without the disadvantage of having to allocate a set amount of memory for it. See tmpfs(7FS) for more information. 2) You might see this behaviour because ps(1) doesn't tell the whole truth. The SZ column of ps(1) output does not reflect the real size of the process to the virtual memory system. Of particular importance to the questioner here, is the fact that memory allocation is done in a lazy fashion under SVR4 (i.e., no memory, either RAM or anonymous memory (another name for swap) is actually allocated until really needed by the process). This means that if ps(1) reports a size of, say, 100 pages, then this is the number of pages that the process has reserved, regardless of whether they are all in use. If only half are required at the moment, then as time goes by more pages could be used, but the size of the process reported by ps(1) will not change. If a program does not "know" until runtime how much memory it will need to allocate (a common case is where the amount of memory is determined by some user input) then you will see the SZ column of ps(1) change, because it wouldn't have been able to take into account the amount of memory the process would need to reserve. DATE APPROVED: 09/16/96 KEYWORDS: less swap space process size OS RELEASE: Solaris/SunOS 2.5.1/5.5.1 INFODOC ID: 14120 SYNOPSIS: How Solaris 2.x uses swap slices as virtual memory DETAIL DESCRIPTION: The Solaris 2.x system software uses some disk slices for temporary storage rather than for file systems. These slices are called swap slices. Swap slices are used as virtual memory storage areas when the system does not have enough physical memory to handle current processes. The Solaris 2.x virtual memory system maps physical copies of files on disk to virtual addresses in memory. Physical memory pages which hold the data for these mappings can be backed by regular files in the file system or by swap space. If the memory is backed up by swap space it is referred to as anonymous memory because the user doesn't know the names of the files backing the memory. Solaris 1.x anonymous memory pages are mapped using randomly assigned names from the system's swap space pool. These memory pages are used for: - Private copies of data created during copy-on-write operations - Process and stack segments - The tmpfs file system storage resources The limitations of the Solaris 1.x anonymous memory implementation are: - Physical storage (disk-backed swap) must always be reserved for anonymous memory mappings even if the application doesn't use it. For example, applications with large data segments must be configured with lots of swap space even if the pages are not written out to physical storage. - The formula used to associate an anonymous memory page with physical storage is limited and inflexible because the backing store is chosen at random and can never be changed. The Solaris 2.x software environment introduces the concept of virtual swap space, a layer between anonymous memory pages and the physical storage (or disk-backed swap space) that actually back these pages. A system's virtual swap space is equal to the sum of all it's physical (disk-backed) swap space plus a portion of the currently available physical memory. Virtual swap space has these advantages: - The need for large amounts of physical swap space is reduced because virtual swap space does not necessarily correspond to physical (disk) storage. - A pseudo file system called swapfs provides addresses for anonymous memory pages. Because swapfs controls the allocation of memory pages, it has greater flexibility in deciding what happens to a page. For example, it may change the page's requirements for disk-backed swap storage. PLANNING FOR SWAP SPACE The most important factors in determining swap space size are the requirements of the system's software applications. For example, large applications such as CAD simulators, database- management products, transaction monitors, and geologic analysis systems can consume as much as 200-1000 Mbytes of swap space in very large memory systems. Consult your application vendor for swap space requirements for any application whose data files typically exceed 10-20 Mbytes in size. If you are unable to determine swap space requirements from the application vendor, use the following guidelines to allocate swap space: - To support your applications, allocate: - 1 Mbyte per trivial application such as xterm - 2-3 Mbytes per lightweight application such as a calendar or mail application. - 20-50 Mbytes for large applications such as desktop publishing software. - To save crash dumps, allocate 100% of physical memory to save a worst-case crash dump. - If you are unsure of system or application requirements, allocate 50 to 100% of the system's physical memory. For example, allocate 16-32 Mbytes of swap space for a system with 32 Mbytes of physical memory. This will provide 48-64 Mbytes of total virtual swap space. - Determine whether large applications (like compilers) will be using the /tmp directory. Then allocate additional swap space to be used by tmpfs. PRODUCT AREA: System Administration PRODUCT: Device config SUNOS RELEASE: Solaris 2.x HARDWARE: any