| Chapter Syllabus 9.1 Swap Space, Paging, and Virtual Memory Management 9.2 How Much Swap Space Do I Need? 9.3 Configuring Additional Swap Devices 9.4 When Dump Space Is Used 9.5 Including Page Classes in the Crashdump Configuration 9.6 Configuring Additional Dump Space 9.7 The savecrash Process 9.8 Dump and Swap Space in the Same Volume In Chapter 8, we looked at a major use of volumes, i.e., filesystems. In this chapter, we look at the two other main uses of disk and volumes: swap and dump space. Arguably, there is a fourth use ”raw volumes ”but in those scenarios the volumes are under the control of some third-party application and are, therefore, outside this discussion. An age-old problem is how much swap space to configure. On large-memory systems these days, we will invariably configure less swap space than main memory. This flies in the face of the old rule-of-thumb of " at least twice as much swap space as main memory. " We discuss pseudo-swap , how it is configured, and why the virtual memory system is considered a paging system as opposed to a swapping system. Most conversations regarding swap space somehow lead to discussions of dump space. I think this is a legacy from the time when our dump space had to be configured as part of the root volume group ( vg00 ), and by default, the dump space was configured as being our primary swap device. Yes, I agree that we need to configure a certain proportion of disk space just in case our system crashes and we want to preserve the crashdump. But like swap space, there was an old rule-of-thumb something along the lines of "at least 1.5 times the amount of main memory. " This rule-of-thumb needs revising! And when we find a crashdump, what do we do then? In reality, we need the services of our local HP Response Center in order to diagnose why the system crashed. In my experience, what we as administrators can do is to provide as much relevant information as possible to the Response Center to assist them in gaining access to the crashdump files so that they can start a root-cause-analysis investigation. In this chapter, we simply look at the sequence of events that occur as a result of a system crash. In the next chapter, we look at how to distinguish between a PANIC, a TOC, and a HPMC. This will influence whether we place a software support call or hardware support call, which can help our local Response Center make some basic decisions on how to initially deal with the problem. In the end, all we want is the speediest resolution to the problem. | 