You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
La création d’instances peut entrainer une charge mémoire complexe à prévoir, notamment dans la cas de la création de table, dont le nombre d’instances dépendant des données des bases en entrée.
Le problème de dimensionnement des ressource se pose notamment dans le cas de tables externes, qu'il faut charger intégralement en mémoire, et qui peuvent impliquer des instances créées par des règles de création de tables.
Analyse du problème
Cas des instances des tables externes
Le cas des instances de tables externes est complexe, car l’ensemble des instances des tables externes doit être chargé en mémoire, y compris pour leur structure en flocon
En effet, une instance d’analyse peut référencer une ou plusieurs instances externes (par exemple une référence à un produit dans chaque log d’achat d’un client)
Et depuis cette instance externe accéder potentiellement à ses sous-tables
Il est nécessaire de dimensionner a priori la mémoire occupée par le chargement de l’ensemble des table externes
Pour dimensionner correctement la tâche en cours : savoir a priori si on peut lancer la tâche, et savoir combien d’esclave on peut lancer simultanément, compte tenu de la RAM disponible
Cette estimation est déjà effectuée, avec une fiabilité « raisonnable » compte tenu des usages actuelle des tables externes
Dimensionnement « réaliste » sur la base d’un échantillon des tables externes
ComputeNecessaryMemoryForReferenceObjects
dimensionnement heuristique sans lecture des données
L’implémentation actuelle, bien que précautionneuse, n’est pas robuste au cas d’instance éléphants dans les tables externes, et pourrait échouer en erreur fatale (manque de RAM) si une instance éléphant est présente hors de l’échantillon utilisé pour le dimensionnement
Dans le cas de la création de table, ce problème est accru
Problème grave (erreur fatale potentielle)
Mais rare : table externe peu utilisée, et instances éléphant dans les tables externes peu probables
Problème à résoudre néanmoins
Solutions envisagées
Solution par limitation de l’expressivité des dictionnaires des tables externes
Il s’agit de contraindre l’expressivité de des calcul dans les tables externes pour en faciliter le dimensionnement
Inconvénient : complexe à gérer, à la fois pour les utilisateur de Khiops, et pour l’implémentation
Solution par nettoyage adaptatif
exploiter les mécanisme de protection contre les instances éléphants dans le chargement des tables externe
garder le dimensionnement heuristique selon l’échantillonnage pour réserver un espace mémoire dédié au chargement des tables externes
charger le maximum d’instances externe en mémoire, en ignorant les instances les plus volumineuse, avec warning utilisateur
inconvénient pour l’utilisateur : le résultat dépend des ressources mémoires
Solution par auto-adaptation des ressources
Suite au dimensionnement heuristique, charger le maximum d’instances externes en mémoire, et s’arrêter quand on a dépassé les ressources
Si ceci est effectué dans un esclave par exemple, rendre une nouvelle estimation des ressources nécessaires et recommencer les traitement sur la base du nouveau dimensionnement
Inconvénient : complexe à implémenter
Solution retenue
Solution par estimation exacte des ressources nécessaires
Dimensionner en utilisant 100% des instances externes, au lieu d’une estimation heuristique basé sur un échantillon
Arrêt potentiel si au fur et à mesure si on dépasse toute la RAM disponible
Avantage :
traitement rigoureux et exacte du problème de dimensionnement
coût d’implémentation faible
Inconvénient
On va charger les tables externes deux fois en mémoire, une fois pour le dimensionnement (dans le maitre), une fois pour les traitements (dans chaque esclave, comme c’est déjà le cas)
Mais ce n’est pas trop grave
Cas des tables externes volumineuse assez rare
Temps de chargement des tables externes faible devant les temps de traitement dans la plupart des cas
Au pire, un facteur deux en temps de calcul, si tout le temps est pris par le chargement en mémoire des tables externess
Solution retenue
Bon compromis entre fiabilité de la solution, simplicité de l’implémentation, et surcoût en temps d’implémentation
Context
Khiops version: après V11
The text was updated successfully, but these errors were encountered:
Description
La création d’instances peut entrainer une charge mémoire complexe à prévoir, notamment dans la cas de la création de table, dont le nombre d’instances dépendant des données des bases en entrée.
Le problème de dimensionnement des ressource se pose notamment dans le cas de tables externes, qu'il faut charger intégralement en mémoire, et qui peuvent impliquer des instances créées par des règles de création de tables.
Analyse du problème
Cas des instances des tables externes
Solutions envisagées
Solution par limitation de l’expressivité des dictionnaires des tables externes
Solution par nettoyage adaptatif
Solution par auto-adaptation des ressources
Solution retenue
Solution par estimation exacte des ressources nécessaires
Context
The text was updated successfully, but these errors were encountered: