Page 2 of 2

Posted: Thu Oct 16, 2003 7:00 am
by mhester
What Ken Bland states is correct for the following reason -

I would go for the 8 "CPU's" instead of 1. Let us say that you had a job queue that had one very long job running acceptably, then ever thing else in the queue has to wait for service. With the 8 CPU's, the wait time of the short times is no longer worsened by the presence of long jobs in the queue. This is queing theory and in my opinion what Ken states and this post makes sense.

Also, it does matter if you are on a box that has either Symmetrical or Asymmetrical Multiprocessors because in the asymmetric model a cpu does a certain thing (like I/O) and that is all it does, whereby in a symmetric model all of the cpu's share the workload.

To answer your question, which has been answered, would be to only change things that you can like cache or adding more cpu's with more memory.

Regards,

Michael Hester

Posted: Thu Oct 16, 2003 7:07 am
by Amos.Rosmarin
You can increase the MFILES to 500
and the RLTABSZ to 250



Amos

Posted: Thu Oct 16, 2003 7:47 am
by kcbland
[quote="chuarkai"]
May I repeat my last question again, any one has any suggestion or any rule of thumb to tune UVCONFIG ???
quote]

The only items I've ever had to touch are:

MFILES=50
T30FILES=1000

In my experience T30FILES has to be upsized because it sets a limit on the maximum number of dynamic hash files that can be open on your system. You will have unexplained intermittent errors if you're running a large number of jobs simultaneously. If each job has 5 supporting internal hash files open during execution, plus an average of say 3 work hash files in your design, then 8 hash files * 30 jobs means 240 is the limit before weird things happen. I believe the default is 200, so things will break if you are running a lot of instantiated jobs. I usually up this value to 1000 to 2000.

MFILES deals with a rotating file pool, and needs to be correctly calculated. Just don't go up this thing to 1000. If you need to up it, call tech support.

Otherwise, you will probably not get dramatic performance increases by playing with these values. Performance is gained through smart ETL design, exploiting hash lookups, small modular jobs, and instantiation to maximize cpu utilization.

Posted: Fri Oct 17, 2003 7:31 pm
by ray.wurlod
A lot of work has gone into setting appropriate default values for the tuneable parameters in the uvconfig file. So the rule of thumb that chuarkai seeks is "leave it alone" or seek expert assistance.

To gain in-depth information about this file you would need to take IBM's UniVerse System Administration class (also known as UniVerse Core Technologies), followed by IBM UniVerse Advanced Technologies.

A few of the posters on this list (Ken, Kim and me for example) have a background in the UniVerse product, so are reasonably well equipped to deal with tuning.

Be wary that untutored fiddling with some tuneable parameters can actually lead to severly degraded performance. This are highlighted in the comments within the uvconfig file.

Posted: Fri Oct 17, 2003 7:33 pm
by ray.wurlod
A lot of work has gone into setting appropriate default values for the tuneable parameters in the uvconfig file. So the rule of thumb that chuarkai seeks is "leave it alone" or seek expert assistance.

To gain in-depth information about this file you would need to take IBM's UniVerse System Administration class (also known as UniVerse Core Technologies), followed by IBM UniVerse Advanced Technologies.

A few of the posters on this list (Ken, Kim and me for example) have a background in the UniVerse product, so are reasonably well equipped to deal with tuning.

Be wary that untutored fiddling with some tuneable parameters can actually lead to severly degraded performance. This are highlighted in the comments within the uvconfig file.


(oops! and for some reason I cannot delete my own posts in this forum)

Posted: Sat Oct 18, 2003 4:24 pm
by stotman
We are presenting two DataStage Tips & Tricks sessions at Ascential World later this month - one for DataStage Designers and another for DataStage Operators.

In the Performance Tuning component of the Designer Session we are going to share a summary of what we've learnt on customers sites (small to large around the world) not to mention several months living in various hardware vendor benchmark labs last year (lack of sunlight gives you such a great non tan 8)).

After we've presented it I'll post a short summary here.

Cheers

Steve

p.s. Ascential has a specific group of consultants that specialize in providing this sort of advice as well.