× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.





>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 thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 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.