Memory pools
A memory pool is a logical division of main memory or storage that is reserved for processing a job or group of jobs. On your system, all main storage can be divided into logical allocations called memory pools. By default, the system manages the transfer of data and programs into memory pools.
The memory pool from which user jobs get their memory is always the same pool that limits their activity level. (The activity level of a memory pool is the number of threads that can be active at same time in a memory pool.) Exceptions to this are system jobs (such as Scpf, Qsysarb, and Qlus) that get their memory from the Base pool but use the machine pool activity level. Additionally, subsystem monitors get their memory from the first subsystem description pool, but it uses the machine pool activity level. This allows a subsystem monitor to always be able to run regardless of the activity level setting.
Why use memory pools
You can control how much work can be done in a subsystem by controlling the number and size of the pools. The greater the size of the pools in a subsystem, the more work can be done in that subsystem.
Using shared memory pools allows the system to distribute jobs for interactive users across multiple subsystems while still allowing their jobs to run in the same memory pool.
Multiple pools in a subsystem help you to control the jobs' competition for system resources. The advantages of having multiple pools in a subsystem are that you can separate the amount of work done and the response time for these jobs. For example, during the day you may want interactive jobs to run with good response time. For better efficiency you can make the interactive pool larger. At night you might be running many batch jobs, so you make the batch pool larger.
Although tuning and managing your system can help the efficiency of the flow of work through your system, it cannot account for inadequate hardware resources. Consider a hardware upgrade if the demands of your workload are significant.
How data is handled in memory pools
If data is already in main storage, it can be referred to independently of the memory pool it is in. However, if the needed data does not exist in any memory pool, it is brought into the same memory pool for the job that referred to it (this is known as a page fault). As data is transferred into a memory pool, other data is displaced and, if changed, is automatically recorded in auxiliary storage (this is called paging). The memory pool size should be large enough to keep data transfers (paging) at a reasonable level as the rate affects performance.
- Types of memory pools
On the your system, all main storage can be divided into logical allocations called memory pools. All memory pools in a system are either private or shared. There are private memory pools, shared memory pools, and special shared memory pools. As many as 64 memory pools, in any combination of private and shared pools, can be active at the same time.- Pool numbering schemes
Pools have two sets of numbering schemes: one is used within a subsystem and one is system-wide. The subsystem uses a set of numbers that refer to the pools it uses. Thus, when you create or change a subsystem description you can define one or more pools and label them 1, 2, 3, and so on. These are the designations of the subsystem pools, and they do not correspond to the pool numbers shown on the Work with System Status (WRKSYSSTS) display.- Memory pool allocation
When you start a subsystem, the system attempts to allocate the user-defined storage pools that are defined in the subsystem description of the started subsystem.- Memory pool activity level
The activity level of a memory pool is the number of threads that can actively use the CPU at the same time in a memory pool. This allows for efficient use of system resources. The system manages the control of the activity level.
Parent topic:
ConceptsRelated concepts
Managing memory pools