Re: Storage pools and QHTTPSVR and QUSRWRK subsystems

On 09/02/2009, at 4:23 AM, Lukas Beeler wrote:

As far as i have understood the OS/400 architecture (and i'm wrong:
please correct me here - there are people on this list that know far
more about this than me), memory is never used explicitly - this is
because of the single level storage system. Instead, the bits adressed
are always on-disk somewhere (or not yet, if not explicitly
synchronised). Memory just acts a giant disk cache, if compared to
other architectures like Windows, Linux or AIX, where memory is
explicitly adressed and allocated (and the "hack" of swapping was
invented to use more memory than is physically installed).

Generally correct. There is no "swap file" and main storage can be thought of as a cache for disk but data must be moved from disk to main storage before it can be processed. The way this happens is a sort of "sleight of hand". Objects have a single virtual address. That virtual address is mapped to a real address. The real address will be either an auxiliary storage address or a main storage address. This is why we say there is only ever a single copy of an object. Part of it may be addressable in main storage while the remainder is on disk but ALL of it is in the same virtual address space. The part that is found in main storage is no longer addressable on disk even though it still occupies space on disk. Compare this with other systems that rely on a swap file. They have a copy of an object (say word.exe) on disk, the user runs that program and the entire thing is loaded into virtual storage (i.e., copied into the swap file), and now you have two copies of word.exe, one on disk and one in virtual storage, delete the object on disk and you can continue to run the copy in virtual storage. Try deleting a program object that is in use on XPF and see what happens. A learning experience will ensue.

This will allow the IBM i to work with even extremely low amounts of
memory compared to other architectures, but obviously with a brutal
degradation of speed.

Speed degradation only occurs when main storage is over-committed and you'll get that happening on "swap file" based systems too. Watch what happens when WinDOS runs out of swap space. Unix isn't pretty either when that happens. OS/400 will only fail when auxiliary storage is full although if main storage is over-committed you'll get "thrashing" as the system spends more and more of its time paging stuff out of and in to main storage in an attempt to accomplish work.

However, as long as 5250 is used this can be
negligible as the system does not have to directly interprete data
entered on the 5250 terminal, instead the data is sent to the IBM i
screen-by-screen instead of key-by-key like vt100 terminals did.

It's true that the host system does not have to concern itself with echoing individual keystrokes back to the terminal (who thought that would be efficient) but each screen of data results in some further processing--usually database related--and it is this activity that can kill performance of even 5250 workload if there is insufficient main storage to adequately service the number of 5250 sessions. In addition we have issues caused by insufficient disk arms and gutless processors.

I suspect the root cause of your upgrade problem was two-fold: 2 disk arms simply isn't enough, CD/DVD drives are notoriously slow, and all I/O is probably going through the same controller. The system is probably spending a lot of time waiting for I/O to occur.

Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists

http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------