|
>From: "Rick Rayburn" <the400man@hotmail.com> > >wait...so I should add 62,500 k to machine pool from the 1 gig? > Yes -- If you add 1 gigabyte of memory (and the machine pool was correctly sized before you added the memory) you will need to add something like 62,500 kilobytes to the machine pool to handle the "virtual address" mechanism for that gigabyte of memory. I have seen people buy a bunch of memory and get significantly _worse_ performance because their machine pool was too small. But the real way to tell if there is enough memory in the machine pool is to watch the non-database faulting rate (with the WRKSYSSTS command for a few minutes at a time) when the system is fairly busy. If the machine pool non-database faulting rate is almost always under 5 faults per second, you probably have enough memory in the machine pool. Similarly, if you get everything but the operating system jobs out of *BASE and get enough memory in that pool, your non-database faulting will be less than 10 faults per second most of the time. If the faulting is higher, you most likely have some disruptive jobs running in that pool with your operating system. I have had to put as much as 30 megabytes of memory in *BASE to get the faulting down after I have taken batch and communications and everything else that can be removed out of the *BASE pool. Most systems I have seen recently have lots and lots of memory and it is being mostly wasted. I can tell because they have an automatic tuner moving memory around like crazy - the faulting is still high - the bottleneck is usually the disk resources (don't get me started on that topic) - the CPU is not being fully utilized - and the solution to any performance problem is to buy more CPU or more memory. That's what I think anyway. Your mileage may vary... -- Charly >>From: "Charly Jones" <charly301@hotmail.com> >> >>> > If it does, any GENERAL rule of thumb to follow for incrementing the >>>MACHINE pool? >> >>First, unless IBM has made some >>major architectural changes that I don't know about, the VAT (virtual >>address translator) mechanism requires some pinned memory in the machine >>pool to keep track of what "real" address is stored in each memory frame. >>If I remember correctly - when you add 16 gigabytes of memory to a system >>you need to put 1 gigabyte of additional memory in the machine pool just >>for >>that purpose alone. The rule of thumb is one sixteenth of the memory >>added >>needs to be added to the machine pool. >> >>> > On Behalf Of Rick Rayburn >>> > Subject: We've Added more memory...but I can't remember! >>> > >>> > ...if I need to "goose" up the machine pool with additional "wattage". >>> > >>> > the memory was added because we got a great deal on the chips NOT >>>because >>> > we >>> > were experiencing problems. I believe all of the additional "K" was >>>dumped >>> > into *BASE but I'm not certain. >>> > Does anyone remember/know if memory additions ALWAYS dump into Base? >>> > If it does, any GENERAL rule of thumb to follow for incrementing the >>> > MACHINE >>> > pool? I believe I OVER-allocated memory to the "SPOOL POOL" by >>>granting an >>> > average of 300 K per active writer. Any thoughts on that as well...or >>> > anything else memory-pool related? >>> > >>> > Thanks all. >>> > >>> > Rick Rayburn >>> >> >> "Nothing would please me more than being able to hire ten programmers and deluge the hobby market with good software." - Bill Gates in 1976 "We are still waiting..." - Alan Cox in 2002 "Linux is only free if your time is worthless." Charly Jones 253 265-6244 Gig Harbor Washington USA _________________________________________________________________ Send and receive Hotmail on your mobile device: http://mobile.msn.com
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.