Yes and no: what you first need to do is to understand your system. This means (among other things) to understand the patterns of resource consumption there are. You might have a relatively stable demand for CPU or a widely varying one. You may have predictable ups and downs (for instance: day=high, night=low, etc.) or event-triggered ones. If your consumption is varying it might be by a small factor or a big one. All these things you can only find out through careful, long-term study of the system. I know these things even less than you, because i know even less about your system. So, please, bear with me for being somewhat general in my suggestions.

Set up and run sar (or nmon or whatever else you like) to monitor consumed resources (memory, CPU, I/O, net, ...) over some time to get a good impression about these usage patterns. The tool you use doesn't matter asl long as it provides the data you are interested.

Run a ps (or top or something alike) to learn about the most demanding processes in terms of memory and CPU. Maybe they run all day, maybe they run only during a certain time of the day. Maybe they run all day but only need very much memory/CPU power during a short time. Maybe ... You see, there is a lot of things not known about your system.

Performance tuning is a very simple task once you have understood where the bottleneck is. Finding out the bottleneck, though, can be extremely difficult. I suggest you read the little tutorial i wrote to get some pointers.

How to tune Java processes or databases is beyond my area of expertise. I take them as they are and leave the tuning to the DBAs and application engineers.

However, we have now seen two situations of your system: one in which it choked under the load and onw where it is (almost) idle. Again: what you need is to find out the pattern behind it.

In general there are three values to every resource you can define in the HMC profile: "minimum", "desired" and "maximum".

"Minimum" is the minimum amount the LPAR needs to allocate, otherwise it won't start.

"Desired" is how much the LPAR grabs if that much is available. This is the normal amount an LPAR has when it starts.

"Maximum" is how much the LPAR can additionally allocate should it be necessary. This additional resources (the difference between "desired" and "max") will be allocated only during runtime.

The reason why this is done that way is that you can "overcommit" the systems resources. If you have 100GB memory installed you can create LPAR profiles worth 150 GB in total. You leave some of them unstarted and/or the last one will only start with something between "minimum" and "desired" in this case.

What you have to do now is to find sensible values for "desired" and "maximum". This, again, can only be done in monitoring the system for some time.


Basically, a "physical CPU" is what you know as a CPU: a processor you can touch. From one such physical CPU one or several "virtual CPUs" are created. The more virtual CPUs are created from one physical CPU the "smaller" the virtual CPUs become. You allocate a number of physical CPUs to an LPAR and state in the LPAR profile how many virtual CPUs to create from these. If you change the allocated number of processors (physical CPUs) this number of virtual CPUs will not change, they will just get more (or less) powerful.

You need one CPU to run a thread (or - the same - a single-threaded process). Still, these threads may have different demands on processing power. Choose as many cirtual CPUs to satisfy all threads and keep them as small as possible, yet as big as necessary - that is the basic idea. What exactly "necessary", "possible", etc., means: see above, monitor and find out.

About threads/processes: in the vmstat output you see "r" and "b" on the left side. If you regularily see big numbers in "r" the system might profit from a raised number of virtual CPUs, even if they are smaller than now. If there are only low numbers you might be able to reduce on the number of lCPUs. Again: not enough data right now to suggest either.

As an afterthought: when you compare the first and second vmstat output you can notice that the numbers in the run-queue ("r") were low in the first but are high in the second. That basically means: there were few but "CPU-heavy" processes running when the first snapshot was taken but many (very lightweight) processes ran during the second. It would be interesting to know which processes these were/are and if there are dependencies. If (for the last time: this is NOT a suggestion, but it might become one if the data back it up) during times of heavy taxation only few, heavy processes run the machine might profit from fewer (but more potent) lCPUs.

I hope this helps.

bakunin