Notice bibliographique
Résumé
Je tiens d'abord à remercier mon directeur de recherche, le Professeur Michel Dagenais, pour m'avoir donné l'opportunité d'accomplir cette maîtrise.Le soutien et les conseils qu'il m'a offerts ont été essentiels pour mener à bien ce travail.Je remercie tous mes collègues du laboratoire DORSAL pour leur esprit d'équipe et le partage des connaissances qui favorisent grandement la réalisation des projets de recherche.Je remercie particulièrement Francis pour sa disponibilité et son expertise dont il m'a fait profiter.Merci à Geneviève et à Mohamad de m'avoir guidé tout au long de mes travaux.Merci aussi à Ericsson, à EfficiOS et au Conseil de Recherches en Sciences Naturelles et en Génie du Canada (CRSNG) pour leur soutien financier qui a permis l'accomplissement de cette étude.Finalement, j'aimerais remercier ma famille, en particulier ma mère pour m'avoir poussé avec une grande patience dans mes études.Un grand merci à mes amis pour leur support constant ces deux dernières années.v RÉSUMÉ L'usage des services infonuagiques connait un essor indéniable au sein des entreprises ces dernières années.Ils exposent, au travers d'Internet, un ensemble de technologies qui donnent accès à des ressources informatiques.Ces technologies permettent de virtualiser les machines physiques, et de fournir aux utilisateurs des ressources virtuelles isolées les unes des autres.Si ce mécanisme d'isolement offre une forme de garantie pour la sécurité des données, il peut cependant engendrer des anomalies de performance.En effet, les systèmes virtuels ont l'illusion d'avoir un accès exclusif à l'hôte et chacun l'utilise sans tenir compte des besoins des autres.Cela entraine des interférences et une baisse de performance des technologies de virtualisation.Pour superviser les services d'une plateforme infonuagique, il est fréquent d'utiliser des applications de gestion.Ces applications ont la particularité de simplifier les interactions des utilisateurs avec les services de l'infrastructure.Cependant, elles peuvent être une source d'incohérence et causer des anomalies d'exécution des requêtes lorsqu'elles sont mal configurées.Nous nous intéressons, ici, aux troubles liés à l'utilisation d'OpenStack comme application de gestion.L'objectif de cette étude est de fournir aux administrateurs, un outil pour surveiller le fonctionnement des opérations dans le nuage et pour localiser d'éventuelles altérations de performance, aussi bien au niveau des couches applications que des couches de technologies de virtualisation.Nous basons notre approche sur le traçage, qui permet de comprendre efficacement les détails d'exécution d'une application.En traçant simultanément les différentes couches de l'infrastructure, il est possible de suivre les requêtes des utilisateurs et de déterminer, de façon précise, les performances des services déployés.Nous utilisons LTTng, un outil de traçage reconnu pour les latences relativement faibles qu'il induit aux programmes diagnostiqués, contrairement aux autres traceurs.Il sera utilisé pour tracer les espaces utilisateurs et noyaux des machines de la plateforme.Les traces des différents systèmes seront collectées et agrégées dans une machine dédiée à l'analyse des performances.L'administrateur pourra alors obtenir un bilan d'utilisation des ressources, détecter les anomalies de fonctionnement des services et par la suite prendre des mesures pour remédier aux problèmes.vi
Récupéré en direct depuis OpenAlex et désinversé. Les résumés ne sont pas conservés dans cette base de données : les index inversés représentent 8,6 Go des 9,3 Go de texte de la base, et le serveur dispose de 13 Go libres.
Comment cette classification a été obtenuedéplier
Prédiction machine sur la base complète
Imitation des enseignantsNi prévalence calibrée, ni vérité terrain. Validation humaine à venir. Le volet Gemma est une étiquette directe du modèle pour chaque travail de la base, lue sur la notice réduite au titre. Le volet Codex est un classifieur appris des 10 348 étiquettes directes de Codex et calibré sur les taux pondérés de l'échantillon; les champs sans appui suffisant ne portent aucun appel Codex. Le mode candidate est l'union des deux volets; le consensus est leur intersection. Ces sorties portent le statut machine_predicted_unvalidated et ne sont pas des étiquettes humaines.
Scores du classifieur distillé par catégorie (deux têtes)
| Catégorie | Codex | Gemma |
|---|---|---|
| Métarecherche | 0,002 | 0,007 |
| Méta-épidémiologie (sens strict) | 0,002 | 0,000 |
| Méta-épidémiologie (sens large) | 0,001 | 0,001 |
| Bibliométrie | 0,004 | 0,003 |
| Études des sciences et des technologies | 0,001 | 0,001 |
| Communication savante | 0,002 | 0,001 |
| Science ouverte | 0,001 | 0,001 |
| Intégrité de la recherche | 0,001 | 0,001 |
| Charge utile insuffisante (le modèle a refusé de juger) | 0,005 | 0,001 |
Scores machine (provisoires)
Les deux têtes enseignantes du modèle étudiant, lues sur ce travail. Un score ordonne la base pour la relecture; il n'affirme jamais une catégorie, et le statut de validation accompagne chaque rangée tel quel.
Scores de référence d'un modèle non mature (critères de maturité non atteints, 7 itérations). Un score ordonne; il n'affirme jamais une catégorie.
score_only:v0-immature-baseline · tel quel depuis la passe de notation : score_only signifie que le nombre peut ordonner les travaux, et qu'aucune étiquette de catégorie n'en découleClassification
machine, non validéePrédiction automatique; un appel candidat d’une seule source (Gemma direct ou Codex distillé), pas un consensus.
Le détail, modèle par modèle et score par score, se trouve en fin de page sous « Comment cette classification a été obtenue ».