how do I determine why refresh is crashing?

[#1]

Not sure if SCRIPTING is the right forum to put this in, but it occurred after a scripting change.

I have changed a dashboard qvw to pull one of its joins from a different source.

When I go to refresh, it goes through all the code, brings up the window that asks me to choose fields to show on the window, but most of the time just hangs there with the little circle spinning.  1 out of 10 times it might run all the way through.

It will say "Not Responding" sometimes on its own, or it will certainly say that if I try to close that window.

When I shut the dashboard and reopen it, the data HAS been refreshed, but it just won't run from beginning to end without hanging in the same spot most of the time.

I checked the log file and didn't see anything amiss.

Any ideas how to sort this out or where to start looking?  Thanks.

Dwight

[swuehl]

I would start checking the data model after a (successful) reload. Any syn keys?

Have you watched the CPU and memory usage?

Could you post a screenshot of your model and / or the document log?

[Gysbert_Wassenaar]

From your description it sounds like the machine might be running out of memory. That could be because of massive joins that need to be calculated or large synthetic keys. I suggest another good look at the data model.

[#4]

No syn keys.  It was a left join, on three key fields, and only 28 records being pulled in.  It is joining one extra field to a table.

I can't post screen or log due to company policy.

Can't see any memory or CPU spikes that I can relate to that process specifically.  It's the production QV server, and it is continually jumping from 12% to 50% cpu usage, even when my process is not up.  memory use goes from 12 to 25gb, regardless.

What is the process going on behind the scenes, after the script has run, and the window pops up asking me to select some fields?  What is it crunching?

[#5]

Ok, I got rid of any data that I think might not be copasetic to make public.

This is the model.  There are 583k records in the summary fact table.  However, it handled 4 left joins previous to the left join I added.

The original way of doing this used ApplyMap, because I was only matching on one field.  Now I'm matching on 3 fields.