do so, you may wish to compare with the next previous version. This would be especially important
if you have one key piece of open source code largely responsible for the performance of a given
partition. There is no way of ensuring that a new distribution is actually faster than the predecessor
except to test it out. While, formally, no open source product can ever be withdrawn from the
marketplace, actual support (from your distributor or possibly other sources) is always a consideration
in making such a call.
y
Evaluate upgrading to gcc 3 or sticking with 2.95.
At this writing, the 3.2 version of gcc and
perhaps later versions are being delivered, but some other version may be more relevant by the time
you read these words. Check with your Linux distributor about when or if they choose to make it
available. With sufficiently strong Linux skills, you might evaluate and perform the upgrade to this
level yourself for some key applications if it helps them. The distribution may also continue to make
2.95 available (largely for functional reasons). Note also that many distributions will distribute only
one compiler. If multiple compilers are shipped with your distribution, and the source isn't dependent
on updated standards, you might have the luxury of deciding which to use.
y
Avoid "awkward" LPAR sizes.
If you are running with shared processors, and your sizing
recommends one Linux partition to have 0.29 CPUs and the other one 0.65 CPUs, check again. You
might be better off running with 0.30 and 0.70 CPUs. The reason this may be beneficial is that your
two partitions would tend to get allocated to one processor most of the time, which should give a little
better utilization of the cache. Otherwise, you may get some other partition using the processor
sometimes and/or your partitions may more frequently migrate to other processors. Similarly, on a
very large machine (e.g. an 890), the overall limit of 32 partitions on the one hand and the larger
number of processors on the other begins to make shared processors less interesting as a strategy.
y
Use IBM's JVM, not the default Java typically provided
. IBM's PowerPC Java for Linux is now
present on most distributions or it might be obtained in various ways from IBM. For both function
and performance, the IBM Java should be superior for virtually all uses. On at least one distribution,
deselecting the default Java and selecting IBM's Java made IBM's Java the default. In other cases,
you might have to set the PATH and CLASSPATH environment variables to put IBM's Java ahead of
the one shipped with most distributions.
y
For Web Serving, investigate khttpd.
There is a kernel extension, khttpd, which can be used to
serve "static" web pages and still use Apache for the remaining dynamic functionality. Doing so
ordinarily improves performance
y
Keep your Linux partitions to a 4-way or less if possible.
There will be applications that can
handle larger CPU counts in Linux, and this is improving as new kernels roll out (up to 8-way is now
possible). Still, Linux scaling remains inferior to OS/400 overall. In many cases, Linux will run
middleware function which can be readily split up and run in multiple partitions.
y
Make sure you have enough storage in the machine pool to run your Virtual Disk function
.
Often, an added 512 MB is ample and it can be less. In addition, make sure you have enough CPU to
handle your requirements as well. These are often very nominal (often, less than a full CPU for fairly
large Linux partition, such as a 4-way), but they do need to be covered. Keep some reserve CPU
capacity in the OS/400 partition to avoid being "locked out" of the CPU while Linux waits for Virtual
Disk and LAN function.
y
Make sure you have some "headroom" in your OS/400 hosting partition for Virtual I/O.
A rule
of thumb would be 0.1 CPUs in the host for every CPU in a Linux partition, presuming it uses a
IBM i 6.1 Performance Capabilities Reference - January/April/October 2008
©
Copyright IBM Corp. 2008
Chapter 13 - Linux
187
