« Réunion du 23-04-2024 » : différence entre les versions

De OSWiki
Aller à la navigation Aller à la recherche
Aucun résumé des modifications
(5 versions intermédiaires par le même utilisateur non affichées)
Ligne 10 : Ligne 10 :
** ce runtime exécutera du code fait pour des versions plus anciennes, lui-même,
** ce runtime exécutera du code fait pour des versions plus anciennes, lui-même,
** seulement, pour une raison lambda, '''.net 3.5''' doit être installé sur Windows.
** seulement, pour une raison lambda, '''.net 3.5''' doit être installé sur Windows.
* '''dotNet 8 ne semble pas être une amélioration pour OpenSim''', le principal problème est sa plus '''mauvaise utilisation de la mémoire'''. '''GC''' https://fr.wikipedia.org/wiki/Ramasse-miettes_(informatique) est à nouveau plus lent à libérer de la mémoire pour le système d'exploitation. Mais les tests sur quelques régions comme osgrid LBSA, ont montré que cela restait dans les limites du raisonnable.
* '''dotNet 8 ne semble pas être une amélioration pour OpenSim''', le principal problème est sa plus '''mauvaise utilisation de la mémoire'''. '''GC''' [https://fr.wikipedia.org/wiki/Ramasse-miettes_(informatique)] est à nouveau plus lent à libérer de la mémoire pour le système d'exploitation. Mais les tests sur quelques régions comme osgrid LBSA, ont montré que cela restait dans les limites du raisonnable.
* Pour '''MacOS''', il faut attendre et voir. DotNet 8 nécessite macOS 12 ou plus. DotNet 6 a besoin de 10.5 ou plus.
* Pour '''MacOS''', il faut attendre et voir. DotNet 8 nécessite macOS 12 ou plus. DotNet 6 a besoin de 10.5 ou plus.
* Davantage d'utilisation de '''SIMD'''[https://fr.wikipedia.org/wiki/Single_instruction_multiple_data]  avec dotNet 8. Le modèle SIMD convient particulièrement bien aux traitements dont la structure est très régulière, comme c'est le cas pour le calcul matriciel.
* Davantage d'utilisation de '''SIMD'''[https://fr.wikipedia.org/wiki/Single_instruction_multiple_data]  avec dotNet 8. Le modèle SIMD convient particulièrement bien aux traitements dont la structure est très régulière, comme c'est le cas pour le calcul matriciel.
Ligne 44 : Ligne 44 :
===Configuration pour  CG  ===
===Configuration pour  CG  ===
* Par défaut GC[https://fr.wikipedia.org/wiki/Ramasse-miettes_(informatique)] fait comme si une application s'exécutait seule sur une machine.
* Par défaut GC[https://fr.wikipedia.org/wiki/Ramasse-miettes_(informatique)] fait comme si une application s'exécutait seule sur une machine.
* CG va s'activer pour commencer à libérer de la mémoire avec des applications qui utilisent 95% de la ram physique  de la machine.
* CG va s'activer pour commencer à libérer de la mémoire avec des applications qui utilisent 95% de la RAM physique  de la machine.
* Modification de la configuration pour demander de libérer la mémoire à la moitié de son utilisation dans  '''OpenSim.runtimeconfig.json''' qui '''est régénéré à chaque compilation''' . On peut voir ce fichier dans '''./OpenSim/Region/Application/'''.
* Modification de la configuration pour demander de libérer la mémoire à la moitié de son utilisation dans  '''OpenSim.runtimeconfig.json''' qui '''est régénéré à chaque compilation''' . On peut voir ce fichier dans '''./OpenSim/Region/Application/'''.
  "System.GC.HighMemoryPercent" : 50,
  "System.GC.HighMemoryPercent" : 50,
Ligne 77 : Ligne 77 :
=Bug=
=Bug=
=== Le problème ===
=== Le problème ===
* Signalement d'un problème de compilation avec la version du jour de la réunion. Base de données mariadb Ver 15.1 Distrib 10.6.15-MariaDB, pour Linux (x86_64)sur une installation neuve.
* Signalement d'un problème de compilation avec la version du jour (2024-04-23). Base de données Mariadb Ver 15.1 Distrib 10.6.15-MariaDB, pour Linux (x86_64)sur une installation neuve.
* Performances du serveur SQL : Série de messages de type  
* Performances du serveur SQL : Série de messages de type  
  19:56:36 - [LOGHTTP]: Slow handling of 1083 POST /xinventory from 192.168.1.9:38252 took 4424ms
  19:56:36 - [LOGHTTP]: Slow handling of 1083 POST /xinventory from 192.168.1.9:38252 took 4424ms
Ligne 88 : Ligne 88 :


=== Causes possibles ===
=== Causes possibles ===
* Pire des cas le disque a commencé à mourir. smart[https://www.malekal.com/smartctl-verifier-son-disque-en-ligne-de-commandes-linux/] dit que le disque est ok
* Pire des cas : le disque a commencé à mourir. smart[https://www.malekal.com/smartctl-verifier-son-disque-en-ligne-de-commandes-linux/] dit que le disque est ok
* Ce sont des problèmes de timing... le serveur mysql est très lent à répondre.
* Ce sont des problèmes de timing... le serveur mysql est très lent à répondre.
* Le changement de mysql.data.dll pourrait avoir un impact
* Le changement de mysql.data.dll pourrait avoir un impact
=== Bilan ===
* Si le problème persiste, un ticket sera publié sur la Mantis.[https://opensimulator.org/mantis/my_view_page.php]


= Source=
= Source=
http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2024-04-23
http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2024-04-23

Version du 26 avril 2024 à 10:35

Changements du code de la semaine

Passage à dotnet 8

Commit e731edfa2e

  • Déplacement de la version minimale de dotnet runtime à 8.x.[1]

Implications

  • OpenSim nécessite dotnet8 runtime pour votre plateforme (ainsi que le SDK si vous souhaitez compiler).
    • opensim maintenant refusera de démarrer sur des runtimes inférieur à 8,
    • ce runtime exécutera du code fait pour des versions plus anciennes, lui-même,
    • seulement, pour une raison lambda, .net 3.5 doit être installé sur Windows.
  • dotNet 8 ne semble pas être une amélioration pour OpenSim, le principal problème est sa plus mauvaise utilisation de la mémoire. GC [2] est à nouveau plus lent à libérer de la mémoire pour le système d'exploitation. Mais les tests sur quelques régions comme osgrid LBSA, ont montré que cela restait dans les limites du raisonnable.
  • Pour MacOS, il faut attendre et voir. DotNet 8 nécessite macOS 12 ou plus. DotNet 6 a besoin de 10.5 ou plus.
  • Davantage d'utilisation de SIMD[3] avec dotNet 8. Le modèle SIMD convient particulièrement bien aux traitements dont la structure est très régulière, comme c'est le cas pour le calcul matriciel.
  • Avec dot.Net le contrôle est difficile. Chaque fois que vous démarrez une région, vous obtiendrez un code natif différent. Par exemple l'utilisation maximale de la mémoire physique de la région de la réunion lors de l'ouverture des sessions est comprise entre 600 et 800 Mo, avec le même code et les mêmes conditions. C'est le résultat du "bruit aléatoire" interne à dotNet.
  • La compilation avec dotNet 8 semble 25% plus lente que pour dotNet 6.

NDLR : Informations en plus de la réunion

Mise à jour de DLL

  • Mise à jour des DLL warp3d et xmlrpc[4]
  • Mise à jour de mysql.data.dll vers la version 8.3.0 [5] : ça s'est mal passé, cela n'a pas fonctionné sur certains arm64 ce qui a nécessité un retour à oracle mysql 8.0.31.0 [6].

llCould obsolète depuis longtemps, suppression de code inutile

  • Commit 50212c240c [7]

Correction dans le code pour MySQL

  • Il y avait de mauvais noms pour certaines colonnes et personne ne s'en est plaint, même pas le runtime.[8]

Mise à jour de libomv

  • Commit b1e0b6d0c7 [9]
  • Déplacé aussi vers dotNet 8.

Core prebuild.xml plus simple

  • Il inclut seulement les dlls nécessaires pour opensim.
  • Compile Linux aussi

Nettoyage d'opensim-libs

  • Suppressions de choses inutilisées

Configuration pour CG

  • Par défaut GC[10] fait comme si une application s'exécutait seule sur une machine.
  • CG va s'activer pour commencer à libérer de la mémoire avec des applications qui utilisent 95% de la RAM physique de la machine.
  • Modification de la configuration pour demander de libérer la mémoire à la moitié de son utilisation dans OpenSim.runtimeconfig.json qui est régénéré à chaque compilation . On peut voir ce fichier dans ./OpenSim/Region/Application/.
"System.GC.HighMemoryPercent" : 50,
  • Sur la région de la réunion la configuration permet une libération de la mémoire à 1% de son utilisation c'est à dire 638Mo.
"System.GC.HighMemoryPercent" : 1,
  • La commande Stats de la console le montre.
GCTotalCommited : 121MB 
GCTotalAvaiable 63849MB 
GCHMthreshold 638MB
  • Les machines exécutant de nombreuses petites régions peuvent avoir besoin de changer cela également.

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.😉


Informations

Adresse des dépôts d'OpenSim

Cela n'inclut pas notre libomv fork

Déplacements des projets d'Andrew Hellershanks

  • Tous ses projets liés à OpenSim on été déplacés de github vers sur gitlab.com. Les copies sur github seront marquées comme archivées. Ceci est dû à l'exigence de 2FA (Double authentification) sur github. Il est difficile de se connecter.

Base de données

Migration : Défis liés à l'utilisation de SQLite dans le contexte d'OpenSim

  • L'utilisation de SqLite peut poser des problèmes, notamment en raison de certaines limitations de SqLite par rapport à d'autres bases de données. Il existe des différences avec MySQL au niveau desfonctionnalités disponibles et de la syntaxe utilisée pour les requêtes. Il faut faire des routines différentes puisqu'il n'y a pas de commentaires sur les tables comme pour MySQL.
  • Les migrations de base de données sont complexes en raison de certaines limitations de SQLite, telles que l'absence de support natif pour les opérations d'ALTER TABLE.
  • Les différences entre SQLite et MySQL nécessitent un traitement individuel, ce qui peut être chronophage mais nécessaire pour garantir le bon fonctionnement de la base de données.

Bug

Le problème

  • Signalement d'un problème de compilation avec la version du jour (2024-04-23). Base de données Mariadb Ver 15.1 Distrib 10.6.15-MariaDB, pour Linux (x86_64)sur une installation neuve.
  • Performances du serveur SQL : Série de messages de type
19:56:36 - [LOGHTTP]: Slow handling of 1083 POST /xinventory from 192.168.1.9:38252 took 4424ms

Puis : 

	20:53:50 - [XInventory]: POST http://192.168.1.9:8003/xinventory took 4700ms 537/80bytes
	20:54:20 - [XInventory] : Erreur de réception de la réponse de http://192.168.1.9:8003/xinventory : La requête a été annulée en raison de l'expiration du délai configuré HttpClient.Timeout de 30 secondes.
	20:54:20 - [INVENTORY ARCHIVER] : Le chargement de l'archive pour Luisillo Contepomi a échoué - La requête a été annulée à cause du délai configuré HttpClient.Timeout de 30 secondes qui s'est écoulé.

Causes possibles

  • Pire des cas : le disque a commencé à mourir. smart[11] dit que le disque est ok
  • Ce sont des problèmes de timing... le serveur mysql est très lent à répondre.
  • Le changement de mysql.data.dll pourrait avoir un impact

Bilan

  • Si le problème persiste, un ticket sera publié sur la Mantis.[12]

Source

http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2024-04-23

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