AIX

We have a BI shop that uses a shared ETL server and a database cluster for the EDW and several different data marts catering to individual business groups.

Of late, we have noticed that a lot of sloppy code has crept in and the ETL server (and sometimes the DB as well) seems to be maxing out on CPU and memory. The indvidual business groups do not want to sponsor any effort to clean the code up - because as they see it, they are getting their reports - however, for IT management, continuing with the existing infrastructure is getting less realistic every day. Of course, our immediate solution is to get budgeted for more hardware (little more memory and re-org our IO).

However, we dont want to find ourselves in this situation again. I was thinking we could define AIX limitations to CPU, and memory to restrict the resource consumption of the individual business applications on the ETL server to a reasonable maximum - and if they need more, have business budget for the additional resources needed.

I meant to ask around how is this working out for others on the forum? Is this a problem at all? Any insights will be truly appreciated!

Most reasonable should be to gather the current usage of resources and also estimate a surplus buffer for future needs so you will have some stable planing for the close future.
You or your management might know best what additional workload might come in the future. Careful planning will also decrease the needs of changes to the infrastructure and resources.
There can always be something happening nobody has seen before hand. CoD (Capacity on Demand) is a feature that comes with p-Series and POWER machines. It means that you have for example a box that is built to it's maximum of 32 CPUs but you actually pay and use for example only 20 of them. If there is dire need because of some failover event happened or a critical workload peak rises up, you can activate for a somewhat low fee those CPU reserves until this critical situation is bypassed. Same is available for memory etc. If you later decide you need more CPU or RAM constantly, you can buy them of course and they are already in the machine. They will only have to be activated.

Here is a short IBM Red Paper that explains CoD:
http://www.redbooks.ibm.com/abstracts/redp4416.html

You also have to keep in mind, that sloppy code will not always be speeded up by pure hardware power. There might be some point where there is not much speedup seen, no matter what you activate.

This is absolutely true.

Sloppy code is usually not only demanding more resources than it ought to demand but also demanding more resources to modify it. That means that software maintenance will be a lot more costly than with good code and this will raise the TCO of the program(s).

If systems you administrate are performance-critical the best advice i can give you: agree to some form of SLA with your customers. Get some number which can be measured - number of transactions, response time in seconds, whatever - and get your customer to agree about some threshold value which will mark the border between their needs being met and their needs being not met.

This is raising demands from the subjective feeling ("i feel the system is somewhat slow today") to an objectively measurable fact. Either the system is "fast enough" or it isn't but as long as you are measured against some gut-feeling of some people whose benevolence is usually in great doubt (they simply don't care if they make life miserable for you) you are fighting an uphill fight.

So get your customers to agree to some value of x which they will deem satisfactorial and every complaint from there on can be measured against this value and proven to be correct (=you have to work) or wrong (=they have to shut up).

I hope this helps.

bakunin