Archives of the TeradataForum

Message Posted: Wed, 21 Mar 2007 @ 23:08:05 GMT

	<Prev	Next>		<<First	<Prev	Next>	Last>>

Just to keep the conversation going, let me offer a thought on "theoretical vs. practical" - the phrase "your mileage may vary" leads to wanting to estimate "practical" cpu seconds per day/hour/minute/second vs. "theoretical". I agree with Allan's offering and am adding to his thinking with this posting.

This technique I call "calibration"

Take CPU seconds per day from either AMPUsage or DBQL over at least a 30 day period. One needs to use Allan's computation to give a guess if the total found is reasonable. Then take the average of the maximum CPU utilization percentages per day and put that percentage next to the CPU seconds. Calculate a third column solving for x where:

CPU Seconds = Percentage of x

As an example 1,000,000 CPU seconds for a day when the average of the maximum CPU utilization shows 50% would estimate your practical maximum of 2,000,000 CPU seconds per day.

1,000,000 = 0.50x X = 2,000,000

Do this computation over a long period of time, maybe 30 days. Take the average of those 30 days.

To me this is the best way to estimate practical vs. theoretical. In practice the system will deliver more or less per day with the variance being queries that heavily do product joins or not. Also when skewing is diminished, the "practical" computation of CPU seconds will increase. Queries doing product joins deliver a higher CPU:IO ratio and burn CPU seconds fast. Skewed queries cause a loss of total practical CPU seconds per day.

I my efforts, I find this calibration computation to be simplest when dealing with the intricate formulas required for coexistence machines.

Best Regards,

Jim LeBlanc

	<Prev	Next>		<<First	<Prev	Next>	Last>>