« Réunion du 12-11-2024 » : différence entre les versions

De OSWiki
Aller à la navigation Aller à la recherche
(11 versions intermédiaires par le même utilisateur non affichées)
Ligne 31 : Ligne 31 :
=== Mesure de l'utilisation du CPU dans OpenSim ===
=== Mesure de l'utilisation du CPU dans OpenSim ===
* Jusqu'à présent, '''la version [[Lexique_des_réunions#dotnet | dotnet]]''' d'OpenSim a montré une '''réduction globale de l'utilisation du processeur de 50%''', ce qui est assez important.
* Jusqu'à présent, '''la version [[Lexique_des_réunions#dotnet | dotnet]]''' d'OpenSim a montré une '''réduction globale de l'utilisation du processeur de 50%''', ce qui est assez important.
* Dans le monde virtuel (In World) '''il n'existe pas de fonction LSL directe''' pour tester l'utilisation du CPU.
* Dans le monde virtuel (In World) il n'existe pas de fonction LSL directe pour tester l'utilisation du CPU.
* '''La fonction indirecte''' que Vincent Sylvester utilisait avec Mono ne fonctionne plus avec Dotnet.  Les chiffres rapportés sont incorrects. Il comparait le temps de réponse du processeur du processeur, qui semblait précis sous Mono. Dotnet rapporte maintenant des valeurs beaucoup plus faibles.
* '''La fonction indirecte''' que Vincent Sylvester utilisait avec Mono ne fonctionne plus avec Dotnet.  Les chiffres rapportés sont incorrects. Il comparait le temps de réponse du processeur. Cela semblait précis sous Mono. Dotnet rapporte maintenant des valeurs beaucoup plus faibles.
* Maintenant, il faudrait prendre en compte le nombre de processeurs ou de [[Lexique_des_réunions#Thread |'''threads''']], ce qui complique les tests.
* Maintenant, il faudrait prendre en compte le nombre de processeurs ou de [[Lexique_des_réunions#Thread |'''threads''']], ce qui complique les tests.
* Sur Windows, il existe des outils de diagnostic qui fournissent des informations directes, mais cela n'est pas indépendant de la plateforme.
* Sur Windows, il existe des outils de diagnostic qui fournissent des informations directes, mais cela n'est pas indépendant de la plateforme.Donc, ils ne sont pas utilisables sous Linux.
* Vincent Sylvester va éventuellement utiliser les raycasts pour faire ces tests.
{{NDLR|fond=white |bord=green|message = <br>
'''Utilisation de raycasts''' :
Il est possible qu'en utilisant des raycasts, Vincent Sylvester puisse simuler une charge de travail en lançant de nombreux rayons simultanément, ce qui pourrait augmenter l'utilisation du CPU et aider à évaluer les performances du serveur.
}}


*🏗️
=== Génération de tuiles de carte===
* Ubit Umarov propose d'utiliser la génération de tuiles de cartes pour tester le CPU. Mais c'est un thread unique qui s'en tient au maximum à 100% du CPU.
* À ce propos, Vincent Sylvester  dit qu'il pourrait peut-être '''paralléliser certaines tâches''' mais il n'a pas encore beaucoup étudié Warp3D et c'est difficile de comprendre la trigonométrie de ce module.
* Il pense aussi que sans avoir fait quoi que ce soit,  '''[[Lexique_des_réunions#dotnet | dotnet]] a amélioré la vitesse de génération des tuiles''' de carte.
* Le module de carte intègre peu de cache, Vincent Sylvester se demande si le fait de '''mettre en cache''' les résultats du rendu des objets et de ne rendre que les objets modifiés n'améliorerait pas les performances au moment de l'exécution.


=== Génération de tuiles de carte===
*🏗️
=== Scripts ===
=== Scripts ===
* '''Les scripts semblent plus réactifs avec [[Lexique_des_réunions#dotnet |dotnet]]''', probablement parce qu'ils traitent plus rapidement la file d'attente des actions qu'ils demandent d'exécuter, de sorte qu'il y a moins de « pile » à parcourir avant d'obtenir un résultat.
* Cette amélioration est certes liée à dotnet mais elle est liée également à l''''amélioration du code de la version 0.9.3 d'OpenSimulator'''.
==== Gestion des surcharges ====
* Mono [https://fr.wikipedia.org/wiki/Mono_(logiciel)] : 
* Dotnet :
*🏗️
*🏗️


= Source=
= Source=
http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2024-11-12
http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2024-11-12

Version du 22 novembre 2024 à 13:11

Changements du code de la semaine

Avertissement

Attention : Ce résumé existe pour orienter vos recherches. Des erreurs d'interprétation ne sont pas à exclure. Pour plus de précisions, veuillez vous référer aux sources ou vous adresser directement aux développeurs d'OpenSimulator en assistant aux réunions du mardi ou sur le canal IRC. Je ne fais pas partie des développeurs, ne vous adressez pas à moi pour les joindre. Merci.😉


Base de données

Migration

  • Vincent Sylvester a testé le nouveau système de migration de la base de données . Cela lui a donné des informations utiles sur certains oublis.
  • Le système semble prometteur, il faudra encore quelques semaines de tests en production et il devrait être prêt pour qu'Ubit Umarov l'intègre au code.

Informations

OSCC 2024

  • Formation des conférenciers : samedi 16 novembre à 9h00 AM fuseau horaire PST (heure normale du Pacifique).

Maintenance de la grille Osgrid

  • La réunion n'a pas lieu sur Osgrid qui est hors-ligne pour une maintenance.
  • Extrait des informations trouvées sur le site d'Osgrid et traduites dans DeePL [1]:
Nous sommes actuellement en mode maintenance sur OSgrid. Cela signifie que la grille est hors ligne. Pour faire court, notre cluster de stockage était apparemment à court d'espace. Notre cluster utilise ceph. Il s'agit du service de stockage d'objets pour le système de fichiers distribués Ceph. Il gère les données sur le stockage local avec redondance et fournit un accès à ces données sur le réseau. Ce démon écrit vos assets sur le disque dans de minuscules paquets. Aujourd'hui, OSgrid dispose de 17 ans de données, ce qui représente environ plusieurs centaines de millions d'actifs.
[...]
Date de mise en œuvre du correctif ? 
Dès que possible en ce qui nous concerne. Nous ne voulons pas casser ou négliger des choses en nous précipitant, ni remettre les choses en ligne trop tôt et bloquer le processus. Nous pouvons le mettre en ligne, mais l'expérience nous a appris que ce n'est pas parce que les choses sont possibles qu'elles sont nécessairement intelligentes.
[...]
Pourquoi cela prend-il autant de temps ? Cela prend du temps parce qu'il s'agit simplement d'une grande quantité de données et que la machine fait ce qu'elle peut. 
[...]
Avons-nous perdu des assets / allons-nous en perdre à cause de cette opération ? Rien ne doit être perdu ! Techniquement. Charger et réécrire des données et les enregistrer à nouveau ne devrait pas causer de problèmes dans le cadre d'opérations normales. Nous étions conscients du problème et nous l'avons résolu avant qu'il ne devienne incontrôlable.
  • Il n'est pas certain qu'Osgrid soit de retour pour la prochaine réunion.

CPU : Mono et Dotnet

Mesure de l'utilisation du CPU dans OpenSim

  • Jusqu'à présent, la version dotnet d'OpenSim a montré une réduction globale de l'utilisation du processeur de 50%, ce qui est assez important.
  • Dans le monde virtuel (In World) il n'existe pas de fonction LSL directe pour tester l'utilisation du CPU.
  • La fonction indirecte que Vincent Sylvester utilisait avec Mono ne fonctionne plus avec Dotnet. Les chiffres rapportés sont incorrects. Il comparait le temps de réponse du processeur. Cela semblait précis sous Mono. Dotnet rapporte maintenant des valeurs beaucoup plus faibles.
  • Maintenant, il faudrait prendre en compte le nombre de processeurs ou de threads, ce qui complique les tests.
  • Sur Windows, il existe des outils de diagnostic qui fournissent des informations directes, mais cela n'est pas indépendant de la plateforme.Donc, ils ne sont pas utilisables sous Linux.
  • Vincent Sylvester va éventuellement utiliser les raycasts pour faire ces tests.
NDLR  :

Utilisation de raycasts : Il est possible qu'en utilisant des raycasts, Vincent Sylvester puisse simuler une charge de travail en lançant de nombreux rayons simultanément, ce qui pourrait augmenter l'utilisation du CPU et aider à évaluer les performances du serveur.


Génération de tuiles de carte

  • Ubit Umarov propose d'utiliser la génération de tuiles de cartes pour tester le CPU. Mais c'est un thread unique qui s'en tient au maximum à 100% du CPU.
  • À ce propos, Vincent Sylvester dit qu'il pourrait peut-être paralléliser certaines tâches mais il n'a pas encore beaucoup étudié Warp3D et c'est difficile de comprendre la trigonométrie de ce module.
  • Il pense aussi que sans avoir fait quoi que ce soit, dotnet a amélioré la vitesse de génération des tuiles de carte.
  • Le module de carte intègre peu de cache, Vincent Sylvester se demande si le fait de mettre en cache les résultats du rendu des objets et de ne rendre que les objets modifiés n'améliorerait pas les performances au moment de l'exécution.

Scripts

  • Les scripts semblent plus réactifs avec dotnet, probablement parce qu'ils traitent plus rapidement la file d'attente des actions qu'ils demandent d'exécuter, de sorte qu'il y a moins de « pile » à parcourir avant d'obtenir un résultat.
  • Cette amélioration est certes liée à dotnet mais elle est liée également à l'amélioration du code de la version 0.9.3 d'OpenSimulator.

Gestion des surcharges

  • Mono [2] :
  • Dotnet :
  • 🏗️

Source

http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2024-11-12

Récupérée de « https://cogito.no-ip.info/cogito/OSWiki/index.php?title=Réunion_du_12-11-2024&oldid=11124 »