Slow performance in a small cube
Posted: Tue Sep 13, 2016 1:46 pm
We have a cube we use to designate cube dependencies at server restart: }System - Cube Dependencies.
It has two dimensions:
Counter: 135 elements 0-134 plus a consolidation element TOTAL.
}System - Dependency Measure with two elements, Base Cube and Dependent Cube.
There is a cube: "}Picklist_}System - Cube Dependencies" The picklist values in this cube are: "dimension:}Cubes" for all leaf elements.
The problem:
This cube will not open within a reasonable amount of time, taking 10-15 seconds to open a 2 x 16 view. Once a cell is edited, it invariably "locks up," flashing like it is trying to render the cube view with the message "(Not Responding)." We have waited as long as 30 minutes just to see if the cube view ever renders again. It does not and we kill the thread.
In our DEV environment, it works just fine. A copy of the problematic UAT environment was copied down to DEV and functions flawlessly. Both servers are VMs with 64GB of memory. The UAT server has less than 30GB in use for the two instances running on it. Both instances have the same problem with this cube. Other cubes, including another "}System -" cube with a picklist cube for it does not have a problem, although that cube does not use a picklist based on a control dimension.
Other cubes in the UAT environments do not seem to have a problem. The problem cube has been destroyed and rebuilt, along with its picklist cube as well.
We do experience slower response times with the UAT server.
What could be causing this? Could it be something related to network traffic (the UAT servers are located in a different data center)? What are some things to check?
It has two dimensions:
Counter: 135 elements 0-134 plus a consolidation element TOTAL.
}System - Dependency Measure with two elements, Base Cube and Dependent Cube.
There is a cube: "}Picklist_}System - Cube Dependencies" The picklist values in this cube are: "dimension:}Cubes" for all leaf elements.
The problem:
This cube will not open within a reasonable amount of time, taking 10-15 seconds to open a 2 x 16 view. Once a cell is edited, it invariably "locks up," flashing like it is trying to render the cube view with the message "(Not Responding)." We have waited as long as 30 minutes just to see if the cube view ever renders again. It does not and we kill the thread.
In our DEV environment, it works just fine. A copy of the problematic UAT environment was copied down to DEV and functions flawlessly. Both servers are VMs with 64GB of memory. The UAT server has less than 30GB in use for the two instances running on it. Both instances have the same problem with this cube. Other cubes, including another "}System -" cube with a picklist cube for it does not have a problem, although that cube does not use a picklist based on a control dimension.
Other cubes in the UAT environments do not seem to have a problem. The problem cube has been destroyed and rebuilt, along with its picklist cube as well.
We do experience slower response times with the UAT server.
What could be causing this? Could it be something related to network traffic (the UAT servers are located in a different data center)? What are some things to check?