500 optimize task dimensioning for table creation rules #776
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Issue de correction corespondante sur le site: KhiopsML/khiops-doc#139
KWDRBuildDummyTable: regle de creation de table avec parametre de nombre d'instance crees - regle interne, uniquement a fins de tests de volumetrie de te de crash tests
Bug identifie suite a test de creation de table volumineuse avec la regle BuildDummyTable - dans KWObject::ComputeAllValues, en cas de depassement memoire, on nettoye les variables de calcul temporaire en les detruisant et les remettant dans leur etat initial (etat Forbidden de KWType) - cela permet de tenter de calculer d'autres variables, meme au prix du recalcul des variables temporaires - il se peut qu'a la fin de ce processus, il reste des variables temporaires en etat Forbidden - dans ce cas, cela fait planter la methode Mutate, qui ne s'attend pas a trouver des variable dans cet etat Correction de bug dans KWObject::Mutate - lors d'une mutation, on peut trouver des Objet ou ObjectArray non calcules s'ils ont ete nettoyes par le MemopryGuard lors du ComputeAllValues - ces objets ne sont pas a muter dans ce cas, et on gere maintenant l'etat Forbidden
De meme que KWMTDatabaseMapping, sous classe de KWDataPath, etst gere dans un fichier KWMTDatabaseMapping.h, on deplace la classe KWObjectDataPath dans un fichier KWObjectDataPath.h: - pour faciliter la maintenance - probleme de dependance cyclique resolu en incluant le fichier KWClass.h dans le header - implementation de la gestion de Get|SetDataPathManager dans KWDataPath KWDatabase - utilisation directe de l'objet objectDataPathManager et non d'un pointeur, maintenant que le probleme de dependance cyclique est resolu
Acces centralise au memory guard, pour Impacts:
- KWObjectDataPathManager
- Set|GetMemoryGuard: parametrage centralise d'un service de protection memoire
- positionne dans KWDatabase::KWDatabase()
- comme chaque KWObject connait son data path, il peut alors acceder au
data path manager, et par la au memory guard
- KWObjectDataPath
- GetMemoryGuard: acces generique au service de protection memoire
- utilise dans KWDRRelationCreationRule::NewTargetObject
KWDatabaseMemoryGuard: extension des service au cas de la creation d'instance par des regles
- nouvelles methodes
- AddCreatedRecord
- Set|GetMaxCreatedRecordNumber
- IsMaxCreatedRecordNumberReached
- GetCreatedRecordNumberBeforeLimit
- GetTotalCreatedRecordNumber
- Set|GetCrashTestMaxCreatedRecordNumber
- IsSingleInstanceMemoryLimitReachedDuringCreation
- adaptation des messages utilisateur
- GetSingleInstanceVeryLargeLabel
- GetSingleInstanceMemoryLimitLabel
Gestion de la creation d'instances, en exploitant le memory guard
- KWDRRelationCreationRule
- NewTargetObject
- peut maintenant retourner NULL en cas de probleme memoire
- memorisation des statistiques de creation d'instance
- FillViewModeTargetAttributes: tolere desormais un objet cible NULL
- FillComputeModeTargetAttributesForVariableOperandNumber: tolere desormais un objet cible NULL
Autre impacts
- KWDatabase
- Set|GetMemoryGuardMaxCreatedRecordNumber
- PLShared_MTDatabaseTextFile: serialisation
- PLShared_STDatabaseTextFile: serialisation
- KWCrashTestParametersView: edition du nouveau parametre CrashTestMaxSecondaryRecordNumber
- KWObject
- CleanNativeRelationAttributes: correction d'un require
- ComputeAllValues
- pas de tentative de nettoyage si memoire limite depasse, mais que cela est du aux creation d'instances
- en effet, cela fausserait les resultats de calcul exploitant les instances creees
- ComputeObjectArrayValueAt
- nettoyage des tableaux d'instances crees en cas de depassement memoire, pour eviter qu'il contiennt des valeurs NULL
- KWDRBuildDummyTable
- ComputeObjectArrayResult: correction
- _kht_check_results.py: ajout d'un pattern de resilience aux variations de message d'erreur
pour la stabilisation des resultst de comparaison dans LearningTest
Dans le cas d'instances elephants, tout ne peut pas etre charge en memoire, et les variables calculees sont toute mise a la valeur manquantes. Si un critere de selection implique une instance elephant, la valeur de ce critere est erronee (basee a tort sur des valeurs manquantes), et le resultat de selection depend de la memoire disponibles, et peut meme varier selon la passe de traitement de donnees. On detecte desormais ce probleme dans la passe de lecture KWDatabase::Read // Warning : Si le calcul de la selection entraine un depassement de capacite memoire, // cela peut potentiellement conduire a une valeur de critere de selection incorrecte, // et donc a une non-selection a tort. // Ce warning sera emis en fin de methode si necessaire pour les instances selectionnees. // Il est important d'informer l'utilisateur de ce probleme potentiel, car selon la passe de // traitement des donnees (statistiques basiques, preparation, etc.), les instances selectionnees // pourraient varier, entrainant une incoherence dans le nombre d'instances issues de chaque passe. // Cette incoherence est detectee, mais elle peut avoir plusieurs causes: // fichier modifie entre deux passes, critere de selection mal calcule (comme ici), ... Autre impact: - _kht_check_results.py: ajout de patterns de resilience pour stabiliser les resultats de LearningTest Ajout de jeux de test: - LearningTest\TestKhiops\CrashTests\MaxMTRecordNumberSelection - LearningTest\TestKhiops\TableCreationRules\MaxCreatedInstanceNumberSelection Note: la vraie correction a ce probleme est assez complexe, et fera l'objet d'une issue Mais c'est loin d'etre prioritaire, ce probleme etant tres rare.
On estime maintenant la memoire necessaire pour la creation des instances selon une methode heuristique
Impacts principaux:
- KWDataPath
- GetParentDataPathAt: acces au data path parent a une profondeur donnees
- GetDataPathAttributeTypeAt: type des attributs du data path
- GetEstimatedMemoryForObjectCreation: estimation heuristiue de la memoire necessaire pour la creation d'instances
- KWClass
- GetEstimatedUsedMemoryPerObject
- remplace KWDataTableDriverTextFile::GetEstimatedUsedMemoryPerObject, supprime
- PLMTDatabaseTextFile
- ComputeMemoryGuardOpenInformation: prise en compte des data path des instances creees
- PLSTDatabaseTextFile: ajout de methode similaire a celle de PLMTDatabaseTextFile
- ComputeMemoryGuardOpenInformation
- KWDatabaseTask
- MasterInitializeDatabase: parametrage du memory guard dans le cas general
Supression de methodes inutiles
- PLDatabaseTextFile::GetEstimatedUsedMemoryPerObject
- PLDatabaseTextFile::GetEstimatedUsedMemoryPerObject
- PLSTDatabaseTextFile::GetEstimatedUsedMemoryPerObject
- PLMTDatabaseTextFile::GetEstimatedUsedMemoryPerObject
Refactoring pour simplifier l'acecs au memory guard d'une database
- KWDatabase
- GetMemoryGuard, GetConstMemoryGuard: acces direct au memory guard
- Supression des methodes de type wrapper
- Set|GetMemoryGuardMaxSecondaryRecordNumber
- Set|GetMemoryGuardMaxCreatedRecordNumber
- Set|GetMemoryGuardSingleInstanceMemoryLimit
- KWDatabaseMemoryGuard
- Set|GetEstimatedMinSingleInstanceMemoryLimit
- Set|GetEstimatedMaxSingleInstanceMemoryLimit
- supression des methodes analogues des classes PLDatabaseTextFile, PLSTDatabaseTextFile, PLMTDatabaseTextFile
Nouveaux tests dedies:
- LearningTest\TestKhiops\TableCreationRules\MaxCreatedInstanceNumber
- LearningTest\TestKhiops\TableCreationRules\MaxCreatedInstanceSnowflake
- LearningTest\TestKhiops\TableCreationRules\MaxCreatedInstanceSelection
- LearningTest\TestKhiops\TableCreationRules\MaxCreatedInstanceIris
- LearningTest\TestKhiops\TableCreationRules\MaxCreatedInstanceAccident
marcboulle
force-pushed
the
500-optimize-task-dimensioning-for-table-creation-rules
branch
from
764dbb2 to
b9e903e
Compare
marcboulle
requested review from
carinehue
and removed request for
bruno-at-orange
marcboulle
force-pushed
the
500-optimize-task-dimensioning-for-table-creation-rules
branch
from
b9e903e to
d4e12e1
Compare
marcboulle
deleted the
500-optimize-task-dimensioning-for-table-creation-rules
branch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Il s'agit essentiellement de la gestion des instances "éléphant", dont le volume est tel que la mémoire disponible n'est pas suffisante pour la lecture des records du flocons de données et le calcul des attributs dérivés.
Ce problème est déjà gérè dans le cas des schémas multi-table en flocons.
Avec les règles de création d'instances, ce problème peut arriver en mono-table comme en multi-table, si des des règles de création d'instances créent trop d'instances.
Il faut donc dimensionner la mémoire pour pouvoir gérer des instances éléphants de taille raisonnable, la contrôler au fur et a mesure de l’exécution des règles en cas de dépassement mémoire, et émettre des messages utilisateur les plus intelligible possible en cas de problèmes.