Discussion :

[Seneg33]

Bonjour,

J'ai un soucis de RAM...
En effet j'ai un serveur (8giga de RAM) ou je fais tourné mon application QV.
Je ne fessais tourné que une partie des données afin d'être plus rapide sur la phase de recette, mais j'ai testais sur la totalité des données ....

et mon serveur est a la ramasse et ne peut tout faire tourné. Je voudrais savoir si il y a une règle qui me permettrais d'estimé ma RAM nécessaire ?

Je suis ouvert a toutes proposition, cela m'éviterais de dire a mon patrons :
"j'ai 10 fois plus de ligne, il me faut 72 Giga de RAM en plus !"

Cordialement

[PhunkyBob]

Voila comment je fais mon estimation de RAM nécessaire :

Pour un QlikView Desktop sur une machine 32 bits, il faut compter 1 Go nécessaire pour QlikView + (2 * taille de l'application).

Pour un QlikView Desktop sur une machine 64 bits, il faut compter 2 Go nécessaire pour QlikView + (2 * taille de l'application).

Pour le serveur, en 64 bits, c'est 4 Go minimum, et après ça dépend du nombre d'utilisateurs simultanés.

mon serveur est a la ramasse

- Quelle est la taille de votre appli ?
- Utilisez vous le fichiers directement dans le client lourd, ou est-ce que vous passez par "ouvrir sur le serveur" (voire utilisez l'interface web) ?
- Le serveur se trouve à quelle distance ? (genre vous êtes en France et le serveur est aux USA)
- Passez-vous par un VPN ?


Les problèmes de lenteur avec QlikView viennent par par ordre de priorité :
- une mauvaise utilisation des expressions (des "if" là où on pourrait utiliser des set analysis, des dimensions calculées là où elle pourraient être précalculées, ...)
- une mauvaise modélisation (beaucoup de personne ont tendance à faire plein de tables qui ne servent qu'à enrichir une information d'1 seule table de fait --comme ce qu'on fait dans un modèle relationnel traditionnel-- or QV est un modèle associatif et préfère donc avoir tout dans la même table, présence de clés synthétiques, de clés synthétiques de clés synthétiques, ...)
- pas d'optimisation des tables (utilisation de la table à granularité la plus fine pour effectuer un calcul macro alors qu'on pourrait précalculer ces informations au chargement, ...)
- trop de couches réseau entre le serveur et le client (distance, VPN, ...)
- et en tout dernier, une volumétrie trop importante

Une application bien faite, qui ne présente pas des graphs tirés par les cheveux (beaucoup de calculs relatifs difficiles, ...) contenant une table de faits de plusieurs millions de lignes peut très bien tourner sur un poste "standard" (WinXP / 3 Go de RAM).


Donc avant de mettre la faute sur le serveur, vérifiez qu'il n'y a pas des trucs à améliorer dans votre appli avant

[Seneg33]

bon alors déjà je me suis mal exprimer ^^
mon serveur sature, il me dit que je n'ai pas asse de mémoire et il arrête la mise a jours des données.

et oui on utilise l'interface WEB et notre serveur est en france

[PhunkyBob]

mon serveur sature, il me dit que je n'ai pas asse de mémoire et il arrête la mise a jours des données.

C'est sur la tache de rechargement (reload) que vous avez ce message (message que vous trouvez dans les logs je suppose) ?
(dans ce cas là, je suis vraiment surpris, car même s'il y a peu de mémoire RAM, tant qu'il y a de la place sur le disque dur, il n'y a pas de raison que ça plante si vous n'avez pas de cas de boucle infini dans votre script)

Ou alors c'est quand vous naviguez dans votre application, suite à une sélection (par exemple) vous avez un graph qui mouline pour se mettre à jour, et vous finissez par avoir un message d'erreur ?

Dans ce cas là, les sources de problème sont celles citées plus haut.

- Quelle est la taille de votre appli ?

- Vos tables de faits représentent combien de lignes ?
- Vous arrivez à charger l'application depuis le client lourd quand vous ouvrez le fichier ".qvw" ?
- Vous utilisez quelle version de QlikView Server ? 32 / 64 bits ?
- Vous utilisez le serveur web intégré ou IIS ?
- Quel est l'OS du serveur ?
- Avez vous fait vous même l'install ou est-ce un prestataire qui s'en est occupé ?

[Seneg33]

Bonjour,

c'est en effet sur la tache de rechargement que le problème se pose.
en regardant la console, toutes la mémoires est utilisé est cela fais planter l'application. C'est un assez gros problème, mais une chose me tracasse plus.

L'application sans les tables de fait (avec 40 table fournit par la client) marche.
Alors que l'application (la même) mais avec moins de table et 3 table de fais ne marche pas.

Et quand je dit ne marche pas, c'est remplie toutes la RAM et fais planter l'appli.

Je ne comprend pas ...

Cordialement

[FORMULARY]

Ce qui doit poser problème vient certainement d'une jonction qui se fait mal.
J'ai eu le cas où je liais une période avec une autre table, et la aussi la mémoire de mon PC explosait. En cherchant , je me suis aperçu qu'une période indiquait "2012-01" et l'autre "2012-1" (je n'ai toujours pas compris pourquoi, d'ailleurs)
Comme mes tables faisaient l'une 2 millions d'enregistrements et l'autre 3 millions, vous imaginez le bordel. Seuls 3 mois sur 12 passaient ...
J'ai résolu mon problème en loadant date(maperiode,'YYYY-MM') as maperiode ...

Essayez de recharger en limitant le nombre d'enregistrements ou en sélectionnant vos enregistrements puis vérifiez le contenu de vos zones de jonction ...

[PhunkyBob]

J'ai du mal à comprendre ce que veut dire "fait planter l'application".

Le service QVS plante ? Ou c'est simplement la tache qui se retrouve avec un statut "error" ?

Est-ce que quand vous rechargez avec le client lourd, cela fonctionne correctement ?

Essayez de recharger en limitant le nombre d'enregistrements ou en sélectionnant vos enregistrements puis vérifiez le contenu de vos zones de jonction ...

Dans la fenêtre de script, au lieu de faire "recharger", vous faites "debugger". Vous pourrez dire de ne charger que 1000 lignes / table (par exemple).

Encore une fois :

- Quelle est la taille de votre appli ?
- Vos tables de faits représentent combien de lignes ?
- Vous arrivez à charger l'application depuis le client lourd quand vous ouvrez le fichier ".qvw" ?
- Vous utilisez quelle version de QlikView Server ? 32 / 64 bits ?
- Vous utilisez le serveur web intégré ou IIS ?
- Quel est l'OS du serveur ?
- Avez vous fait vous même l'install ou est-ce un prestataire qui s'en est occupé ?

(après, j'abandonne)

[SteffieLili]

J'ai exactement le même problème sur une application Qlikview client. Mon ordinateur au bureau ne dispose "que" de 4Go de RAM (je dis "que" car chez moi et à la fac c'était au delà de 8Go). Mes tables me génèrent au total plus de 6 millions de lignes et j'avoue que l'utilisation d'une petite clause "If" fait "ramer" l'application. Cela marche mais dès que je dois agrandir une fenêtre, rajouter une liste de sélection ou même enregistrer, cela met 10 ans. J'ai vu l'utilisation des set analysis, je vais me pencher la dessus. Mais étant donné le nombre de lignes important sur ma BDD, faut-il rajouter de la RAM sur ma tour et si oui, de combien aurais-je besoin ?

[PhunkyBob]

Pour un QlikView Desktop sur une machine 32 bits, il faut compter 1 Go nécessaire pour QlikView + (2 * taille de l'application).

Pour un QlikView Desktop sur une machine 64 bits, il faut compter 2 Go nécessaire pour QlikView + (2 * taille de l'application).

Avant de revoir à la hausse les ressources de l'ordinateur, il vaut mieux se pencher sur l'optimisation de l'application.

Exemple simple : vous avez 6'000'000 de ligne dans votre appli.
Vous voulez la somme des ventes d'un jour.
Vous faites

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

sum(if(Jour = JourChoisi, Ventes))

Ca mettra des plombes.

Mais si ous faites

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

sum({$ <Jour={'JourChoisi'}>} Ventes)

le calcul sera quasi instantané !


Le fait de mettre des conditions de calcul permet aussi de faire en sorte que votre application ne calcule pas des trucs inutiles.



Sur les grosses tables, vous pouvez aussi créer des tables pré-agrégées qui permettent de faire des graphs optimisés.

Bref, il y a beaucoup d'axes possibles avant l'upgrade matériel.

[SteffieLili]

C'est noté Pas mal d'optimisations à étudier donc !

[Davidb_]

Il y a aussi la technique du WHERE EXISTS(Champ1,Champ2) qui peut permettre d'optimiser le poids de grosses applications en limitant le chargement des données.

- Utilisez vous le fichiers directement dans le client lourd, ou est-ce que vous passez par "ouvrir sur le serveur" (voire utilisez l'interface web) ?

Il y a une grosse diff au niveau des perf entre ces différents moyens de connexion ?

après ça dépend du nombre d'utilisateurs simultanés.

Il y a une règle a ce niveau la pour estimer la charge que represente chaque nouvel utilisateur ? Après je suppose que ça dépend du graphe sur lequel l'utilisateur est en train de cliquer...

[PhunkyBob]

Il y a une grosse diff au niveau des perf entre ces différents moyens de connexion ?

Oui.
Ouvrir un fichier ".qvw" qui est sur son disque veut dire que tous les calculs seront faits par notre CPU.
Ouvrir un fichier sur le serveur veut dire que c'est le serveur qui fera tous les calculs. Notre CPU ne fera que les afficher.


Ainsi, si vous avez une toute petite config mais que vous vous connectez à un gros serveur, vous aurez une application rapide.

Il y a une règle a ce niveau la pour estimer la charge que represente chaque nouvel utilisateur ?

Oui, il y a une équation fournie par Qlik qui donne une estimation. J'essayerai de la retrouver....

[SteffieLili]

Et me revoici avec de nouveaux problèmes de RAM.
Le principe de mon application est d'enrichir chaque année la base de données Qlikview en se servant de bases de données Access. A chaque année correspond une base de données Access différente.
Le rechargement du script avec la première année se réalise sans soucis ainsi que la première table de la seconde année (connexion à la seconde BDD et LOAD de la première table qui contient tout de même 4 millions de lignes). Cependant, dès lors que le script essaie de charger la deuxième table de la BDD 2, il m'affiche une erreur de mémoire vive (et oui encore). J'ai essayé sur mon mac (partition Windows of course) qui possède 8Go et j'ai la même erreur au même endroit.
Y a t-il des améliorations possible pour les LOAD ?

[PhunkyBob]

il m'affiche une erreur de mémoire vive

C'est à dire ?


Question bête : utilisez-vous bien la version 64 bits de QlikView ?

Y a t-il des améliorations possible pour les LOAD ?

Toujours !

- Stocker les données des années précédentes (qui sont figées) dans des QVD pour charger depuis les QVD plutôt que la base de données.
- Ne pas stocker toutes les lignes, mais des tables pré-agrégées avec uniquement les données dont vous avez vraiment besoin.
- ...

[SteffieLili]

C'est à dire ?

Voici l'erreur exacte :
OUT OF VIRTUAL AND/OR LOGICAL MEMORY, allocating 2MB

Ceci dans une première fenêtre puis une autre fenêtre s'ouvre avec :
Server deployment compatibility warning internal insconsistency, type D, detected. If the application is deployed on a server, the server will restart with the message above written to the event log. Please contact QlikTech support for further assistance.

utilisez-vous bien la version 64 bits de QlikView ?

Et bien non, l'équipe informatique me l'a installé sur mon pc de bureau et ce n'est pas la version 64Bits mais la 32Bits. Cela pose t-il un problème ?

Et pour les améliorations, et bien je vais perfectionner tout cela au maximum mais j'ai l'impression que cela ne suffira pas, surtout que mon pc de boulot ne possède que 4Go (dites moi si je me trompe)

[PhunkyBob]

l'équipe informatique me l'a installé sur mon pc de bureau et ce n'est pas la version 64Bits mais la 32Bits. Cela pose t-il un problème ?

La version 32bits ne peut prendre que 2 (?) Go en RAM, alors que la version 64bits peut prendre ce qu'elle veut (dans la limite des stocks disponibles).

Ca peut faire une différence.

internal insconsistency, type D, detected.

Généralement, ce genre d'erreur est liée à une mauvaise jointure.
Là où une grosse table devrait être liée à une autre grosse table par 1 champ, il y a une jointure complète (par exemple parce qu'il n'y a aucun champ commun). QlikView essaye alors de faire le produit cartésien de "plein de lignes" par "plein de lignes", et ça pète.

Vous pouvez faire un chargement avec l'option "debug" et limiter votre chargement à quelques milliers de ligne. Si le résultat donne une table de 1 million d'enregistrement, c'est qu'il y a un problème.

[SteffieLili]

La version 32bits ne peut prendre que 2 (?) Go en RAM, alors que la version 64bits peut prendre ce qu'elle veut (dans la limite des stocks disponibles).

Je vais avoir la possibilité de tester la version 64 Bits sur 16Go cet après-midi (vive la fac de sciences et ses bêtes de compétition ). Je vais même essayer je pense de baisser la RAM de la machine virtuelle pour voir si j'ai vraiment besoin d'autant de RAM que ça. Effectivement, j'ai l'impression que c'est un problème d'allocation de mémoire et non pas de la RAM totale présente sur le PC. Cependant, mon PC de bureau a un système d'exploitation 32 bits ... Du coup, je ne pourrai me servir de la version Qlikview 32Bits

Généralement, ce genre d'erreur est liée à une mauvaise jointure.

Et bien, j'ai utilisé la fonction "debug" et cela ne marche que sur très peu de lignes.
Pour un script limité à 10 lignes, je récupère 40 lignes pour les deux plus grandes tables. Donc pour 4 millions initiaux, ca me génèrerait 16 millions de lignes au total pour deux ans. Cela est énorme non ? cela est dû au fait que je concatène les tables chaque année et en plus en fonction de la nature des codes (donc chaque année, je load deux fois ces deux tables (d'où le facteur 4 sur deux ans)).

De plus, j'ai remarqué surtout la génération de clés synthétiques qui me parait incompréhensible. Et forcément, cela me crée des boucles. je pense que c'est la raison pour laquelle tout pète. Le soucis, c'est que ce n'est pas dû à des champs nommés pareils. Cela me mets des champs qui n'y sont pas à la base dans une table ... Comment cela est-il possible ? J'essaie de résoudre ce problème sans grand succès pour l'instant

Voilà un exemple des clés synthétiques générées. Je précise que les champs rsaEtab et rsaCode ne sont absolument pas présents dans la table GHM

[PhunkyBob]

Et bien, j'ai utilisé la fonction "debug" et cela ne marche que sur très peu de lignes.

La fonction "debug" vous permet de choisir le nombre de lignes que vous souhaitez charger au niveau QlikView.
Mais si la requête SQL initiale doit retourner 6 millions d'enregistrements, alors elle sera tout de même exécutée avant que QlikView y applique son filtre.

Voyez si vous pouvez limiter le chargement directement dans la requête SQL (en précisant une condition temporelle pour ne récupérer que les données d'1 mois par exemple).

De plus, j'ai remarqué surtout la génération de clés synthétiques qui me parait incompréhensible. Et forcément, cela me crée des boucles. je pense que c'est la raison pour laquelle tout pète.

Exactement.

Je précise que les champs rsaEtab et rsaCode ne sont absolument pas présents dans la table GHM

Vraiment très bizarre...
Je n'ai jamais eu de cas d'un rechargement QlikView qui charge des colonnes que je ne lui ai pas demandées...


Vous ne faites jamais de jointure sur votre table "THS_GMS" dans votre script ?

[SteffieLili]

Voyez si vous pouvez limiter le chargement directement dans la requête SQL (en précisant une condition temporelle pour ne récupérer que les données d'1 mois par exemple).

Je vais tester cela. Cela permettra d'avancer plus vite avec mes ressources disponibles et d'optimiser plus.

Vous ne faites jamais de jointure sur votre table "THS_GMS" dans votre script ?

A si, j'en fait une avec la table RSA à l'aide du champs "GHM" (nommé GHM dans les deux tables) C'est cela qui joue sur mes clés synthétiques ?

[SteffieLili]

J'ai résolu une partie du problème en réalisant le LOAD de ma table GHM au début (avant celui de la table RSA et RUM). Cependant, cela me génère une autre clé synthétique entre RUM et RSA ... J'ai l'impression que c'est à cause des "JOIN LOAD".
Voici les tables que cela me génère :


Voici le code en question :

Année 1 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
RSA:
LOAD FINESS & '-' & index_RSA as Id_RSA,
	 FINESS as rsaEtab,
     mode_entree, 
     provenance_entree, 
     mois_sortie as RSA_mois_sortie, 
     annee_sortie as RSA_annee_sortie,
     index_RUM_DP,
     'DR' as rsaNature, // on stocke la nature des codes DR
     DR as rsaCode;
 
SQL SELECT 
* FROM RSA;
 
 
 
JOIN LOAD FINESS AS rsaEtab,
          Raison_sociale AS rsaRaisSoc
          resident Etablissements;
 
JOIN LOAD
     Code as rsaCode, 
     Libelle_court as rsaLibCode 
     resident THS_CIM10;
 
 
 
// ########## CREATION DE LA TABLE DE FAIT RUM ###################
 
RUM:
LOAD 
	FINESS & '-' & index_RSA & '-' & index_RUM AS Id_RUM, // on garde un id_rum pour faire des stats sur le nombre de rum
	FINESS & '-' & index_RSA AS Id_RSA, // on garde le meme id_RSA que celui du load de la table rsa. il servira a compter le nombre de RSA et associer les RSA correspondants au RUM
	FINESS as rumEtab,
 	index_RUM,
    'DP' as rumNature,
    DP as rumCode,
    IGS2,
    Nb_DAS as rumNb_DAS,
    Nb_actes as rumNb_actes,
    duree_sejour as dureeSejour
 
;
SQL SELECT 
* FROM RUM;
 
JOIN LOAD FINESS AS rumEtab,
          Raison_sociale AS rumRaisSoc
          resident Etablissements;
 
 
 
JOIN LOAD Code AS rumCode,
          Libelle_court AS rumLibCode
          resident THS_CIM10;

Sur cette année, aucune clé synthétique n'est générée.

En revanche, quand je m'occupe de la seconde année avec ce code, cela me génère ma clé synthétique.
Année 2:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
concatenate(RSA)
LOAD FINESS & '-' & index_RSA as Id_RSA,
	 FINESS as rsaEtab,
     mode_entree, 
     provenance_entree, 
     mois_sortie as RSA_mois_sortie, 
     annee_sortie as RSA_annee_sortie,
     index_RUM_DP,
     'DR' as rsaNature, // on stocke la nature des codes DR
     DR as rsaCode;
 
SQL SELECT 
* FROM RSA;
 
 
 
JOIN LOAD FINESS AS rsaEtab,
          Raison_sociale AS rsaRaisSoc
          resident Etablissements;
 
JOIN LOAD
     Code as rsaCode, 
     Libelle_court as rsaLibCode 
     resident THS_CIM10;
 
 
 
// ########## CREATION DE LA TABLE DE FAIT RUM ###################
 
concatenate(RUM)
LOAD 
	FINESS & '-' & index_RSA & '-' & index_RUM AS Id_RUM, // on garde un id_rum pour faire des stats sur le nombre de rum
	FINESS & '-' & index_RSA AS Id_RSA, // on garde le meme id_RSA que celui du load de la table rsa. il servira a compter le nombre de RSA et associer les RSA correspondants au RUM
	FINESS as rumEtab,
 	index_RUM,
    'DP' as rumNature,
    DP as rumCode,
    IGS2,
    Nb_DAS as rumNb_DAS,
    Nb_actes as rumNb_actes,
    duree_sejour as dureeSejour
 
;
SQL SELECT 
* FROM RUM;
 
JOIN LOAD FINESS AS rumEtab,
          Raison_sociale AS rumRaisSoc
          resident Etablissements;
 
 
 
JOIN LOAD Code AS rumCode,
          Libelle_court AS rumLibCode
          resident THS_CIM10;

Au moins maintenant je n'ai plus de cycle mais cette clé synthétique ne me plait pas du tout.

En ce qui concerne la RAM, quand je bosse en 64bits, les 8Go sont utilisés et c'est la charge d'écriture qui plante. Elle monte jusqu'à arriver à 100% et pouf, fini, ca plante.