Hi,

I'm using AS2K SP4 32bit on Windon 2003 32bit on Hardware EMT64bit Xeon
2 CPUs. It's a test environment so that no other programs are running.

if I restart Analysis Services and then I process a
partition(20,000,000 rows), It works well. Both CPUs run about 60 - 70%
until the task is done. Then, I process other partitions, it still
works well (CPU 60 -70%).
However, if I process a few dimensions(500,000 members) and then
process a partition in the same cube, it performs badly. When it does
"Writing data of partition 'x'", CPUs perform 60-70%. When it does
"Writing aggregations and indexes of Partition 'X'", CPUs perform about
1%. Or sometime only one thread runs 60-70%, others run 1%.

In my old server, it doesn't cause this problem.


Please give me some suggestion.

Best Regards,
Anote

Hi,

Check if your cubes have the lazzy aggregation on the cube. In the cube
editor select "Advanced" -> "Processing Optimization Mode" should be
"Regular".

Check also if there no "shadow" files being created/updated. Search "*'*" in
the Olap Data directory.

Hope it helps.

"anote_un (AT) hotmail (DOT) com" wrote:

Thanks for your responding.

Currently, Processing Optimization Mode is Regular.

Any comments ?

Anote,
use perfmon and look at the counter "Size Bytes" under "Analysis Services:
Proc Aggs Memory". If this counter always shows "0", no lazzy aggs is
performed.Otherwise, use LazyProcessing.vbs to identify wich partiton is in
lazzy aggs processing.


Ramunas Balukonis


"Tiago Rente" <TiagoRente (AT) discussions (DOT) microsoft.com> wrote

There are no Lazy Aggregation in my cube. I look at the counter
"Memory:Size Bytes", it is always zero.

I don't think it is about lazy aggregation.

Best Regards.

do you have a distinct count measure in the cube?

in my case, the "problem" appeared when I have a cube with standard measures
(sum, min, max & count) and a distinct count measure.
In this case, the processing time is slow down when I advance in the
aggregations...
and sometimes the CPU is 1%.
if you split your measures in 2 cubes (1 with the sums..., 1 for the DCount
measure) you'll see a good processing performance, but 2 cubes to process.

the disk usage for the cubes go from 350mb to 100mb (sums) + 150mb (dcount)


<anote_un (AT) hotmail (DOT) com> wrote

There are no distinct count measure.

The problem I have found is if I didn't process dimension before it
works fine. But I process a big dimension, the CPU runs 1%

I have got exactly the same problem. I have tested it on 3 differen
machines (i am talking about that very same step of writin
aggregations and indexes).
First one is a 6 years old Dell (2x700 Mhz CPUs), which is the fastes
(CPU load is quite high there).
Second is an IBM with 4 hyperthreaded 3.5 GHz CPUs. There it take
longer with CPUs running at 10% or so
The third one is also an IBM 366 with 8 hyperthreaded CPUs. The las
one takes by far the longest time to write indexes (5 times longe
than the second one and 10 times longer than the ancient Del
machine). Only 1% of CPUs is utilized in that case. All AS setting
are the same (except for the maximum number of threads which I als
tried to vary). Totally unexplainable.

Btw, when you wrote about processing of a big dimension before wha
did you mean? Did it mean that you need to process that big dimensio
inside the same transaction as the cube

Kind regards
Dmitri

Another interesting point : the CPUs in my case are also exactly th
same EMT64bit Xeons...
Dmitri

interesting results...
have you try with the hyperthreading disabled?


"Dmitri4321" <dmitri4321 (AT) hotmail-dot-com (DOT) no-spam.invalid> wrote