topic Re: Intervalmatch memory problem in QlikView

Intervalmatch memory problem

Mon, 30 Mar 2015 08:18:20 GMT

Good morning,

in an attempt to optimize one of my reports, i tried to link a campaign products table with the facts table using extended intervalmatch.

So far, i just linked the two tables with the product key and used an if expression to sum up sales within start and end date of the campagin.

When i tried the script with one month of data it worked fine so far. As expected the script reload needed a little more time, but all within normal duration. But as soon as i reload the whole data my application memory allocation explodes.

The fact table for ~28months consists of about 24million lines. The campaign table has at about 1mio distinct product-date frame values.

The strange thing is, that script execution everything works really fine and the intervalmatch doesnt seem to cause any problem, but as soon as the script finishes and the sheet property window is shown, the memory starts to grow indefinitely. Usually i have to kill the process at about 32gb of ram allocation, because the server starts to freeze.

The script is rather straightforward:

TEMPKampagnenzuordnung:

IntervalMatch(%CalendarDate, %CampaignProductKey) LOAD CampaignStartDate, CampaignEndDate, %CampaignProductKey Resident Campaign;

KAMPAGNENZUORDNUNG:

LOAD AutoNumber(%CampaignProductKey& '|' & num(CampaignStartDate) & '|' & num(CampaignEndDate)) as %CAMPAIGNKEY,

AutoNumber(%CampaignProductKey& '|' & %CalendarDate) as %CAMPAIGNSALESKEY

Resident TEMPKampagnenzuordnung;

DROP Table TEMPKampagnenzuordnung;

Drop Field %AktionsArtikelKey;

Does anyone have an idea what could cause this issue - except the huge datamodel

Re: Intervalmatch memory problem

hic — Mon, 30 Mar 2015 09:22:13 GMT

You have two tables initially, the "Campaign" table and a second table that contains "%CalendarDate". Both these tables contain the field "%CampaignProductKey".

Then you (correctly) create a third table "KAMPAGNENZUORDNUNG" to link the two above tables. However, the two initial tables are still linked through the "%CampaignProductKey", which means that you will get a synthetic key that eats memory.

Solution: You need to delete "%CampaignProductKey" from one of these tables at the end of the script, e.g. through

Drop Field "%CampaignProductKey" From "Campaign" ;

HIC

Re: Intervalmatch memory problem

Mon, 30 Mar 2015 09:31:38 GMT

Hi Henric,

thank you for the reply and sorry for my sloppy script example above. I translated the german field names to English for better understanding, but forgot to do the same with the dropped field at the end.

Drop Field %AktionsArtikelKey; = %CampaignProductKey

The datamodel itself looks fine and no synthetic keys or loops so far.

Here a screen loaded with 1 month of data and German names

Re: Intervalmatch memory problem

hic — Mon, 30 Mar 2015 09:39:57 GMT

Dann ist es wahrscheinlich nur die Größe des Datenmodells. Deine Datenmodell sieht perfekt aus.

Was passiert wenn Du nur mit 12 Monaten von Daten versuchts ?

HIC

Re: Intervalmatch memory problem

Mon, 30 Mar 2015 13:46:00 GMT

Konnte das nun endlich austesten, ein Jahr an Daten benötigt etwa 2,5GB RAM und 350MB auf der HDD bei hoher Kompression. Also etwa ein Drittel der Gesamtdaten. Wenn der RAM Bedarf linear zu den Daten steigt sollt ich maximal ja schlimmstenfalls in den 10GB Bereich kommen.

Werd mal schrittweise die Jahre hinzunehmen und schauen wann der Todpunkt erreicht wird.

Interessant ist wie erwähnt eigentlich nur, daß von der Datengröße ja kein sprunghafter Zuwachs erfolgt und der Intervalmatch im Load ja reibungslos funktioniert, nur werden scheinbar irgendwelche Kalkulationen oder Prüfungen im Anschluss aufgerufen die sich im Arbeitsspeicher riesig aufblähen. Zumindest kann ich Chart-Formeln hier schon ausschließen, da die Applikation selbst leer ist

Re: Intervalmatch memory problem

Mon, 30 Mar 2015 14:29:53 GMT

Ok ist mir jetzt etwas peinlich, aber es dürfte zumindest gelöst sein.

Ich hatte zwar keine Charts in der Applikation, aber es waren scheinbar eine ganze Menge Formeln in Variablen hinterlegt und eine bzw. mehrere davon dürften dann durch den Umbau des Datenmodels ein Problem bei der Kalkulation verursacht haben das den Arbeitsspeicher leer gefressen hat. Nachdem ich das Script nun einfachheitshalber in ein neues leeres Dokument übernommen habe, läufts einwandfrei mit den kompletten Daten.

Vielen Dank für deine Ratschläge