Locally openend .qvw very slow

[Anonymous]

Hi all,

since about one week our main App behaves strange. Every thing you do (e.g. Open Script, Open Table Structure, Open Object Properties, Switch to another tab....) takes considerably more time than before. If you open the Task Manager you can see that the CPU goes to 100% at that time. RAM is about 20% so thats not an issue.

Have restarted the whole Server - still the same.

Facts:
- .qvw Size is about 460 MiB

- 11.2 SR 10

- Winodws Server 2008 R2 64 bit

- Data Model has one SynKey. This key has been there since the first start.

Can sombody help me?

edit: I have to say that its not always like that. Sometimes it behaves normal = fast.

[peter_turner]

Hello Philipp,

You say CPU goes to 100% so this would be the problem, is this all the QlikView process?

It could be that the application has some screen objects or charts that are trying to recalculate over the large dataset?

Does this behaviour happen on all sheets? can you make a new sheet and test the performance to open script etc?

[Anonymous]

Using Windows Task Manager on the server can you identify which process[es] are hogging the CPU ?

[Anonymous]

Hi,

Ty for the feedback.

Yes, ist only the Qv.exe that consumes 100% CPU.

It also happen on some older sheets that havent changend in a while and had a normal behaviour .

Even in Document Properties it sometimes goes to 100% for a few seconds.

Reinstalled the QlikView App yesterday --> still the same.

What else can i do?

[marcus_sommer]

In general objects which aren't displayed won't be calculated and if there aren't any selections to be calculate the cpu consumes should be by 0%. But there are exceptions by variables, trigger, calculations within object-title and probably some more which will be more or less continuously calculated. If such calculation includes synthec keys or are going over loosen tables or the system date/time will permanent accessed - they could never ending.

I think you should check these. Maybe it's easierto check in a large app if you worked in copies from the file and removed and/or reduced tables/fields/objects/variables step by step ...

Anothing point could be the system from your server - is it physically or virtual. If it's virtual and some settings had change it could be have heavy effects.

- Marcus

[Anonymous]

The thing is - the same .qvw work perferct in Access Point.

The Server is a virtual host...

[marcus_sommer]

Per access point is ok. but per local fat-client or with fat-client opened on qv server is slow, right? Are all services and the fat-client on the same virtual server? Are there changes with the settings from the vm? Are there upgrades on another qv services release? Releases from server and fat-client are the same?

- Marcus

[Anonymous]

Thats right. All services are on the same host. There have been no changes made in last cpl. weeks. No Updates to Windows and no Updates to the Vware software either.

The only thing that changed was an update from 11.20 SR5 to SR10 but that was 2 Months ago and the problem occured about 3 weeks ago. Client and Server are both the same version.

[marcus_sommer]

Such a change in service release could be cause these differences. Are you sure that the app worked fine within the first 4 weeks after the upgrade? Was on any reason made a reload + save with the fat-client instead of a server update task? Have you an older backup from the app which you could compare against the current one?

- Marcus

[Anonymous]

Sorry for my late reply..

We nailed it down to the fact table.

This table has about 60M Rows and 230 columns. But since its build by several smaller fact tables by using concatenate, it consinsts of many 'null' values.

So, we wrote this table into a .qvd file (yielding in 14GB file size and a RAM footprint of ~16GB).

I went home with this file and opened it on my PC (Intel Xeon 3,3Ghz, 4Cores+4HT, 16GB RAM, fresh .qvw file). Used the 'First' command to keep the RAM footprint under 16GB but it had the same symptoms as the virtual machine with AMD CPUs.

Dont know what to do next...