Adam Thornton wrote:

Do the machines really have to be that large?  Even WebSphere rarely
actually requires 768M.


Overcommitting is good, it's the only way to make people share the
resource. If you have enough resources to avoid sharing you don't need
to encourage it. For WebSphere it obviously that depends on the
application running there. And it depends on what else you run. Most of
the measurements look at throughput in a single virtual machine, but
when you have multiple guests running websphere your target may be
different. Even when you find that it likes 768M (what a wonderful magic
number that is) this may not be what is best to achieve maximum
consistent throughput.

One of the ideas is that you should not mix applications in a Linux
virtual machine because that makes it hard for VM to tell what the guest
is doing and provide proper resources. And when you run WebSphere you
really have 3 different applications in one virtual machine. The
database will attempt to grab all memory to cache the database I/O. The
Java processes tend to take a lot of CPU resources, but only once per
transaction. The front-end web server gets involved several times for a
single transaction (to deliver yet another chunk of http traffic, driven
by the latency of the network).
When you combine the Java processes with the front-end web server the
virtual machine ends up in Q2 or Q3 because it uses a lot of CPU, but
this also means it is dispatched less often. That's too bad because the
web server only uses small amounts of CPU cycles and would benefit from
being serviced quicker. A similar discussion applies to memory usage.
When the database uses memory to cache data from the database, it takes
away the free memory that the web server would otherwise have around to
build buffers for the http data. The individual virtual machines can now
be sized and tuned to meet the requirements.

In the "Performance and Tuning" Redbook SG24-6926 we did some work in
this area and found we could at least get the same throughput in the
configuration with 3 virtual machines (but maximum throughput is not the
only issue). The recent patches to share userspace code in DCSS should
help to cut down the cost of the additional base Linux systems, and make
it even more attractive to break up the application.

Rob

----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Reply via email to