Intel AS/400 RISC Server - Manual (Page 180)

13.4 Basic Configuration and Performance Questions
Since, by definition, iSeries Linux means at least two independent partitions, questions of configuration
and performance get surprisingly complicated, at least in the sense that not everything is on one operating
system and whose overall performance is not visible to a single set of tools.
Consider the following environments:
y
A machine with a Linux and an OS/400 partition, both running CPU-bound work with little I/O.
y
A machine with a Linux and an OS/400 partition, both running work with much I/O or with Linux
running much I/O and the OS/400 partition extremely CPU-bound.
The first machine will tend to run as expected. If Linux has 3 of 4 CPUs, it will consume about 0.75 of
the machine's CPW rating. In many cases, it will more accurately be observed to consume 0.75 of the
CIW rating (processor bound may be better predicted by CIW, absent specific history to the contrary).
The second machine may be less predictable. This is true for regular applications as well, but it could be
much more visible here.
Special problems for I/O bound applications:
y
The Linux environment is independently operated.
y
Virtual disk, generally a good thing, may result in OS/400 and Linux fighting each other for disk
access. This is normal if one simply were deploying two traditional applications on an iSeries, but
the partitioning may make this more difficult to observe. In fact, one may not be able to attribute the
I/O to “anything” running on the OS/400 side, since the various OS/400 performance tools don’t
know about any other partition, much less a Linux one. Tasks representing Licensed Internal Code
may show more activity, but attributing this to Linux is not straightforward.
y
If the OS/400 partition has a 100 per cent busy CPU for long periods of time, the facilities driving the
I/O on the OS/400 side (virtual disk, virtual LAN, shared CD ROM) must fight other OS/400 work
for the processor. They will get their share and perhaps a bit more, but this can still slow down I/O
response time if the '400 partition is extremely busy over a long period of time.
Some solutions:
y In many cases, awareness of this situation may be enough. After all, new applications are deployed in
a traditional OS/400 environment all the time. These often fight existing, concurrent applications for
the disk and may add "system" level overhead beyond the new jobs alone. In fact, deploying Virtual
Disk in a large, existing ASP will normally optimize performance overall, and would be the first
choice. Still, problems may be a bit harder to understand if they occur.
y
Existing OS/400 guidelines suggest that disk utilization be kept below 42 per cent for non-load source
units. That is, controlling disk utilization for both OS/400 and the aggregate Linux Virtual Disks will
also control CPU costs. If this can be managed, sharing an ASP should usually work well.
y
However, since Linux is in its own partition, and doesn’t support OS/400 notions of subsystem and
job control, awareness may not be enough. Alternate solutions include native disk and, usually better,
segregating the Linux Virtual Disk (using OS/400 Network Storage objects) into a separate ASP.
IBM i 6.1 Performance Capabilities Reference - January/April/October 2008
©
Copyright IBM Corp. 2008 Chapter 13 - Linux 180