Re: High Page Faulting in Base and Interactive Pools

Dana,

Memory management is more important than ever now since the types of workloads on the system has expanded greatly over time. When all we ran was batch and 5250, then leaving work management alone was OK, not great but OK. Now with all the different types of workload, Online, batch, WEB, DB/2 access from different sources, SQL access vs. Record Level Access, etc. our systems are far more complicated, and need tuning, both work management and the database.

Think of the system tuning algorithms this way. Assuming no collision threat from in front of you ( meaning you have the road to yourself ) you could drive from your home, to the center of a major city 100 miles away by using nothing but the rear view mirror on the left side of your car. You can keep the car on the road, adjust to turns, etc, by using the side of the road, or the lane lines on the road, but your view would always be at least a second behind the car. Optimal, I'm guessing you would agree it's not. The tuning system while very very good, is always looking at history not current nor anticipated workload.

Add to that the database optimization just works better when the memory pools it's using are not changing constantly causing the optimizer to re-optimize queries all the time, when the only thing that really changed is the memory pool.

Data base I/O is very different from I/O on the IFS and the types of threaded jobs that run in web servers, and other multi-threaded applications are different than your typical historical application. Tuning for it enhances the value of the investment you made in the system and allows the system to work on your business workload, not to manage itself.

Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


On 11/1/2013 3:29 PM, Mitchell, Dana wrote:

Given the more modern hardware and the abundance of memory now days, how important is it to break memory into several pools? Wouldn't the OS be better at moving memory between jobs that humans could be?

Given that, if this system needs a 'major overhaul', how exactly does one determine size and assignments of the pools?

Dana


-----Original Message-----
From:midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Jim Oberholtzer
Sent: Friday, November 01, 2013 3:12 PM
To: Midrange Systems Technical Discussion
Subject: Re: High Page Faulting in Base and Interactive Pools

I would most certainly agree that the memory allocation on this system needs a major overhaul, not a minor one, major. The current configuration is the source of the sensitivity to memory changes, not the reason for it. That said, something that recently happened to upset a system needs to be dealt with first, then come back and set up the work management the way this system needs it.

Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


On 11/1/2013 3:00 PM, Gqcy wrote:

> No, it shouldn't_take_ memory from jobs that need it, but it
> should_give_ memory to the jobs that need it, pulling it from *BASE.
> if you have diverse workloads (e.g. long running batch, short batch,
> java) all competing for memory in *BASE you may well have worse
> performance than you would have if you break out into pools...
>
> Jim has a good lead to follow with Indexing, but I was able to help
> performance by breaking out my work into separate shared memory pools...
>
>
> On 11/1/2013 2:37 PM, Joel Harvell wrote:

>> > *Joel...
>> > others will explain in better detail than me, but you need to
>> > break out your subsystems from*BASE into*SHRPOOLs*...
>> >
>> > I understand about moving SubSystems to other pools, but wouldn't
>> > that actually take memory away from the jobs that need it. This
>> > system is very sensitive to memory allocation. I want to be sure
>> > about the process and the affects before I offer a pool configuration change.

> --

--