Task #2675

Updated by Sebastien Jacquot 10 months ago

Diagnose TXM behaviors processing a large corpora
SJ: WIP, premiers retours



===== Tests performance et ergonomie gros corpus =====

Résumé RAM/CPU/Divers

Commandes
- la RAM allouée à la JVM semble suffisante pour l'ensemble des commandes testées ci-dessous
- grosse consommation CPU de javaw.exe lors du redraw des graphiques JFreeChart lorsque les graphiques contiennet beaucoup d'entités
=> NOTE Dev : vérifier que Java2d utilise bien le GPU, accélération matérielle
- goulet d'étranglement sur les requêtes CQP "[]" (déjà discuté avec MD + tests de fix dans CQPLexicon)
- grosse consommation CPU et RAM de Rterm (jusqu'à 1.4Go sur des grosses CA)
- l'annulation des commandes utilisant R ne semble pas fonctionner (en attente de la réponse du process Rterm.exe je pense car si on kill le process, l'annulation se fait bien)
=> Note dev : est-ce qu'on ajouterait pas un kill de Rterm.exe dans l'annulation + un relancement ?
=> pourquoi on passe par Rterm et pas directement par R
=> A noter que la RAM de Rterm est gérée hors Java, pour la consommation total de la RAM de TXM il faut donc cumuler javaw.exe + Rterm.exe
=> mais comment est gérée la RAM utilisée par cqpjni.dll ? la lib utilise celle allouée à javaw.exe ?

Import
- non testé

==== Corpus ELTECFRAORIG ====

79 fichiers source
Nombre de mots : 7 671 635

-Xms512m -Xmx2048m
Niveau de log à INFO, "mode avancé" non coché, "ajouter des commentaires techniques" coché.
Paramètres par défaut des commandes quand ce n'est pas précisé.
Pics Ram JVM durant la session de travail : ~800M/~1200M of ~1800M

Légende :
RAS = Rien à signaler en termes de performance ou ergonomie
+ => OK
- => Pas OK

* Problèmes généraux
- D'une manière générale, il manque des logs dans la console. (il faudrait rediriger les messages des sous-tâches du Job/Progression vers la console ?)
- L'UI des éditeurs reste accessible lors des calculs long ce qui peut provoquer des bugs sur certaines commandes

* Chargement du binaire

Chargement du corpus binaire au format 0.8.0 ELTECFRAORIG.txm...
=>
Chargement du corpus binaire ELTECFRAORIG.txm au format 0.8.0...

ELTECFRAORIG corpus chargé(s).
=>
Corpus ELTECFRAORIG chargé(s).

* Propriétés
+ RAS
+ vMax = 1000 : RAS
- Titre de l'onglet non traduit "Properties"
- Titre du sous-onglet "Parametres" => "Paramètres"
- mettre "Propriétés" tout en bas du menu contextuel ? + virer "Préférences" ?

* Navigateur
+ RAS
- à l'ouverture de l'éditeur la zone des paramètres avancés est dépliée mais elle est vide

* Edition
+ RAS

* Sous-corpus
- ne marche sur aucun corpus plus depuis la dernière update

* Lexique
- un peu long : ~1.2 sec
- UI commence à ramer lors du tri à partir de 20 000 résultats par page

* Index
+ RAS : faire
+ RAS : [frlemma="faire"] | [frlemma="voir"]

* Cooccurrence
- "faire" : très long ~20 sec
- "pas" : très long ~20 à 40 sec
- javaw.exe et Rterme.exe utilisent énormément de CPU
- manquent des logs

* Progression
+ calcul RAS
- JFC: l'éditeur de graphique rame pas mal dès qu'il y a une plusieurs courbes avec de nombreux points
- JFC : la mise en évidence de nombreux points fait également complètement ramer l'UI
=> Note dev : revoir la 2e passe de tracé des mises en évidence
- JFC: javaw.exe utilise beaucoup de CPU lors du déplacement, zoom dans le graphique

* Wordcloud
+ RAS

*** Partition ELTECFRAORIG_text_booktitle (79 parties)
+ RAS

* Dimensions de partition
+ RAS niveau des performances

* Table lexicale
- très long ~8 à 12 sec
- ne semble pas venir du calcul de fdist mais de la requête "[]" de chaque CQPLexicon, est-ce qu'on ne pourrait ajouter la property à la query ?
- finalement voir : http://forge.cbp.ens-lyon.fr/redmine/issues/2673
-- Fmin = 1, Vmax = 10 000
-- très long ~8 à 12 sec
-- tri sur colonne qui rame

* Index
- "faire", "pas", "lui" : RAS
- "ind*" sort "in" en résultat !

* Spécificités
- manquent des logs
- extrêment long : ~1 min 23 sec
=> Note dev : la table lexicale créée et en fmin = 1 et fmax = 9999999
- Rterm.exe mange beaucoup de CPU
- l'UI rame
- depuis une table lexicale (2/200), long ~10 sec
- depuis une table lexicale (1/10000), long ~45 sec
- problème du rafraichissement des colonnes à l'ouverture de l'éditeur sous Windows qui peut prendre plusieurs secondes.
Retouver le ticket existant.
Le pack des colonnes basé sur la taille du plus long mot est trop lent et les colonnes se refresh une par une très lentement
Voir http://forge.cbp.ens-lyon.fr/redmine/issues/2187


* AFC
- long sans table lexicale ~10 sec
- un peu long depuis une table lexicale (2/200) ~1.5 sec
-- depuis une table lexicale (1/10000)
-- long ~4 sec
-- JFC: graphique illsible
-- JFC: l'éditeur de graphique rame
-- JFC: javaw.exe utilisent beaucoup de CPU lors du déplacement, zoom dans le graphique
- le diagramme des Eigenvalues étant un CategoryChart le zoom ne se fait que sur l'axe Y est les labels des axes ne sont pas lisibles si trop de parties
=> repasser le diagramme en XYChart pour avoir un zoom du même type que dans les dimensions de partition (sur Y et X)
- goulet dans la création de la table lexicale à cause de "[]"

* CA
- long sans table lexicale ~11 sec
-- un peu long depuis une table lexicale (2/200) ~1.5 sec
-- depuis une table lexicale (1/10000)
=> semble planter, attendu 10 minutes
=> dernier log console : Calcul de la CAH...
=> dernier log R eval
R safeEval: try({library(FactoMineR)}, silent=FALSE)
return: FactoMineR, Rserve, stats, graphics, grDevices, utils, datasets, methods, base
R safeEval: try({FactoMineRAHC2 <- HCPC(FactoMineRCA657, cluster.CA="columns", nb.clust=2, metric="euclidean", method="ward", graph=FALSE)}, silent=FALSE)
=> dernière subtask : Computing children of word 1 / 10000: 2 classes colonnes
-- Rterm.exe mange beaucoup de CPU
et surtout 1 400 000 K de RAM
=> le cancel ne semble rien faire
-- même comportement de plantage depuis une AFC (1/10000)



! par ailleurs il reste parfois des .prefs de résultats alors que les résultats ont soit planté (soit été effacés ?)

*** Partition ELTECFRAORIG_speaker_n (257 parties)
- très très long ~2min 20 sec
=> javaw.exe utilise beaucoup de CPU
- j'ai l'impression que le temps de création d'une Part dépend du niveau de la balise dans CQP
par exemple la requête :
[_.sp_n="97"] expand to sp
semble mettre plus de temps à répondre que :
<text_booktitle="Waterloo">[] expand to text
est-ce que c'est normal ? Cela vient de CQP ou bien de l'interfaçage par TXM ?
est-ce que c'est normal qu'on perdre la trace de la hiérarchie originel ? eg. [text_xxx_xxx_sp_n="97"]
Après tests :
1) dans CQP les 2 requêtes semblent aussi rapides
2) cela ne vient pas du flush() après le compute, en le supprimant cela ne change rien
3) on peut voir dans la vue Progression un "Building Workspace (sleeping)" après chaque requête mais en virant "Build automatically" du Workspace, cela ne change rien

* Dimensions de partition
+ RAS niveau des performances

* Table lexicale
- très long ~18 sec
- l'UI rame pas mal
-- Fmin = 1, Vmax = 10 000
-- très long ~20 sec

* Index
+ RAS : faire
+ RAS : [frlemma="faire"] | [frlemma="voir"]

* Spécificités
- manquent des logs

- très long : ~26 sec
=> Note dev : la table lexicale créée et en fmin = 1 et fmax = 9999999
- Rterm.exe mange beaucoup de CPU
- l'UI rame
- depuis une table lexicale (2/200), long ~7 sec
- depuis une table lexicale (1/10000), long ~7 sec
- problème du rafraichissement des colonnes à l'ouverture de l'éditeur sous Windows qui peut prendre plusieurs secondes.
Retouver le ticket existant.
Le pack des colonnes basé sur la taille du plus long mot est trop lent et les colonnes se refresh une par une très lentement
Voir http://forge.cbp.ens-lyon.fr/redmine/issues/2187


* AFC
- long sans table lexicale ~20 sec
- un peu long depuis une table lexicale (2/200) ~2.6 sec
-- depuis une table lexicale (1/10000)
-- un long ~3 sec

*** Sous-corpus ELTECFRAORIG_text_booktitle (de A à F)
+ RAS

* Propriétés
- le noeud est bien créé mais le corpus est vide ?
+ RAS Log CQPJNI :
Information:
Query corpus is empty (and so is the result).


* Lexique Log TXM :
Aucun nom de sous-corpus indiqué, nous avons généré un automatiquement.
Calcul d'un sous-corpus de ELTECFRAORIG, structure text, propriété booktitle : [AmourSwannR1b, Argent, Aziyade, BanditsArizona]
Terminé : ELTECFRAORIG_text_booktitle a été créé

- il faudrait tester que le corpus existe bien dans CQP afin d'indiquer un peu long ~4 sec

message d'erreur plutôt que de dire que tout semnle OK ?

Back