Allocating Enough System Storage to a Subsystem
July 28, 2010 Hey, Joe
|
I want to set up a private storage pool on our i/OS machine for our debit card subsystem. I want to protect its storage since we frequently time out on transactions, even when we run the programs run at priority 16. The debit card programs already run in their own subsystem, but how do I make sure the subsystem pool is getting enough memory? –David There are two ways you can approach this problem: give the subsystem a fixed amount of memory that never varies, or give the subsystem its own shared storage pool that contains a range for how much memory the storage pool can access as needed. Here’s how to perform both techniques. To create a fixed private storage pool for your subsystem, check out this article on fixed storage pools, which shows you how to carve out a specified amount of storage and assign it to a subsystem. The problem is that if you don’t know how much memory to give your subsystem, you would have to first assign a preset amount of memory and then monitor to see if the memory is helping subsystem performance. If you need more memory, you would have to incrementally increase the subsystem’s assigned memory to get better performance. The other downside is fixed storage pools only provide a fixed amount of memory for the subsystem. The operating system won’t automatically increase storage pool memory as needed through i/OS automatic performance adjustment controls. The second technique allows you to provide a fixed minimum amount of memory to your subsystem, while also allowing the operating system to increase storage pool memory as needed. This technique uses i/OS performance adjustment controls, where the system performs automatic storage pool and activity level tuning based on the current workload running in each storage pool. Note: i/OS automatic performance adjustment must be activated for this technique to work. With this technique, you provide your subsystem with its own fixed individual dedicated storage pool whose size can be automatically increased depending on what’s happening on the system. To configure your subsystem to use its own dedicated storage pool, read this article on Moving a Subsystem into its Own Shared Pool. After you assign a dedicated storage pool to your subsystem, you can set that storage pool to use a range between a minimum and maximum amount of system memory at all times. You can do this through two parameters that are associated with every system storage pool.
While the Minimum Size % sets a floor for how much memory the storage pool can access, the Maximum Size % sets up a ceiling that prevents your subsystem from stealing too much system memory from other storage pools. To set up your minimum and maximum dedicated storage pool size range, do the following: 1. Assign a dedicated shared storage pool to your subsystem by following the directions in the Moving a Subsystem into its Own Shared Pool article. 2. Go into the Work with Shared Pools (WRKSHRPOOL) command on your system. Press the F11 key until you find the screen that allows you to set the Priority of the storage pool, its Size % parameters, and its Faults/Second parameters. Go down to the Minimum and Maximum Size % values for your subsystem’s storage pool and change them to the system memory size range that you want to assign to that pool. If you want to assign 10 to 25 percent of your system memory to *SHRPOOL5 that is servicing your subsystem, you can change the *SHRPOOL5 parameters to the following values on this screen:
Work with Shared Pools
Main storage size (M) . : 9612.25
Type changes (if allowed), press Enter.
-----Size %----- -----Faults/Second------
Pool Priority Minimum Maximum Minimum Thread Maximum
*MACHINE 1 11.00 100 10.00 .00 10.00
*BASE 1 8.46 100 12.00 1.00 200
*INTERACT 1 1.00 25.00 12.00 1.00 200
*SPOOL 2 1.00 100 5.00 1.00 100
*SHRPOOL1 2 1.00 100 10.00 2.00 100
*SHRPOOL2 2 1.00 100 10.00 2.00 100
*SHRPOOL3 2 1.00 100 10.00 2.00 100
*SHRPOOL4 2 1.00 100 10.00 2.00 100
*SHRPOOL5 2 10.00 25.00 10.00 2.00 100
*SHRPOOL6 2 1.00 100 10.00 2.00 100
This change takes effect immediately. Once implemented, the system will ensure that when *SHRPOOL5 is servicing your subsystem, it will always assign 10 to 25 percent of system memory to that storage pool. Never more, never less. In a situation where you don’t know how much memory you’ll need, specifying a range ensures that your subsystem gets what it needs without stealing too much memory from your other subsystems. If you have a good system performance monitoring package, like MPG’s Performance Navigator, you can then monitor your subsystem performance to see what other tweaks you might need to make to hit optimum memory allocation for your subsystem. HTH –Joe RELATED STORIES Admin Alert: More Information on Fixed Storage and WRKSYSACT Admin Alert: Moving a Subsystem into its Own Shared Pool Two OS/400 Performance-Adjustment Settings to Check
|
