« Réunion du 23-09-2025 » : différence entre les versions
Apparence
| (9 versions intermédiaires par le même utilisateur non affichées) | |||
| Ligne 11 : | Ligne 11 : | ||
# Lire puis remplacer. | # Lire puis remplacer. | ||
<div class='graphique'">https://zetaworlds.com/images/blog/Disk_Traffic_(md2)_on_eu-cluster2.zetamex.pw3.png</div> | <div class='graphique'">https://zetaworlds.com/images/blog/Disk_Traffic_(md2)_on_eu-cluster2.zetamex.pw3.png</div> | ||
* Avantage supplémentaire, avec l'ancien routine la base de données doit reconstruire les index à chaque opération de suppression et d'insertion ce qui peut entraîner une perte d'efficacité. La nouvelle routine devrait éviter cela. | |||
=== Questions à résoudre === | === Questions à résoudre === | ||
* Il reste à définir les critères ou les conditions qui amènent le système à considérer qu'un objet a été modifié pour l'écrire dans la base de données. | * Il reste à définir les critères ou les conditions qui amènent le système à considérer qu'un objet a été modifié pour l'écrire dans la base de données. | ||
* Vincent Sylvester a consulté les journaux d'audit de la base de données et a remarqué que certains éléments y figurent, mais qu'ils n'ont pas été modifiés activement. | * Vincent Sylvester a consulté les journaux d'audit de la base de données et a remarqué que certains éléments y figurent, mais qu'ils n'ont pas été modifiés activement. | ||
* Il n'a pas encore identifié les facteurs ou conditions qui peuvent activer un indicateur (flag) appelé "hasgroupchanged" ainsi que d'autres indicateurs. Ils pourraient expliquer pourquoi certains objets sont considérés comme modifiés alors qu'ils ne le sont pas. | * Il n'a pas encore identifié les facteurs ou conditions qui peuvent activer un indicateur (flag) appelé "hasgroupchanged" ainsi que d'autres indicateurs. Ils pourraient expliquer pourquoi certains objets sont considérés comme modifiés alors qu'ils ne le sont pas. | ||
* Il est également nécessaire d'avoir un mécanisme pour retirer les éléments qui ne sont plus présents, ce qui est essentiel pour maintenir l'intégrité de la base de données. | |||
=== Discussion === | === Discussion === | ||
| Ligne 20 : | Ligne 23 : | ||
* Andrew Hellershanks émet l'hypothèse qu'une [https://fr.wikipedia.org/wiki/Persistance_(informatique) persistance] intervienne pour écrire les données dans la base de données pour garantir que l'état des objets est correctement enregistré, même en l'absence de modifications détectées. | * Andrew Hellershanks émet l'hypothèse qu'une [https://fr.wikipedia.org/wiki/Persistance_(informatique) persistance] intervienne pour écrire les données dans la base de données pour garantir que l'état des objets est correctement enregistré, même en l'absence de modifications détectées. | ||
* D'après sont test local, Vincent Sylvester confirme que c'est ce qui se passe toutes les 10 minutes environ, mais il n'a pas encore réussi reproduire l'enregistrement des données dans la table "primitems". | * D'après sont test local, Vincent Sylvester confirme que c'est ce qui se passe toutes les 10 minutes environ, mais il n'a pas encore réussi reproduire l'enregistrement des données dans la table "primitems". | ||
* | * Vincent Sylvester suspecte que la réécriture de SetText avec les mêmes données pourrait déclencher des mises à jour inutiles des objets, mais il n'a pas réussi à reproduire ce comportement.De plus, bien que certains objets contiennent des scripts inactifs, ils produisent tout de même des enregistrements. | ||
==== Amélioration possible ==== | ==== Amélioration possible ==== | ||
* Techniquement, l'enregistrement pourraient être amélioré en utilisant [https://dev.mysql.com/doc/refman/8.4/en/insert-on-duplicate.html INSERT ... ON DUPLICATE KEY UPDATE] plutôt que [https://dev.mysql.com/doc/refman/8.4/en/replace.html REPLACE INTO] , mais cela rendrait la requête plus complexe, et Vincent Sylvester ne sais pas comment cela se traduirait côté base de données. Il pourrait en fait y avoir plus de données qu'avec la fonction « REPLACE INTO ». | * Techniquement, l'enregistrement pourraient être amélioré en utilisant [https://dev.mysql.com/doc/refman/8.4/en/insert-on-duplicate.html INSERT ... ON DUPLICATE KEY UPDATE] plutôt que [https://dev.mysql.com/doc/refman/8.4/en/replace.html REPLACE INTO] , mais cela rendrait la requête plus complexe, et Vincent Sylvester ne sais pas comment cela se traduirait côté base de données. Il pourrait en fait y avoir plus de données qu'avec la fonction « REPLACE INTO ». | ||
* Malheureusement, la fonction « REPLACE INTO » effectue toujours une suppression et une insertion avec une reconstruction de l'index, ce qui la rend plus lourde, mais comme la nouvelle routine empêche déjà la réécriture des données existantes, elle réduit considérablement les écritures. | * Malheureusement, la fonction « REPLACE INTO » effectue toujours une suppression et une insertion avec une reconstruction de l'index, ce qui la rend plus lourde, mais comme la nouvelle routine empêche déjà la réécriture des données existantes, elle réduit considérablement les écritures. | ||
* Il existe peut-être d'autres interactions avec la base de données qui pourraient être améliorées de la même manière, mais chaque chose en son temps. | * Il existe peut-être d'autres interactions avec la base de données qui pourraient être améliorées de la même manière, mais chaque chose en son temps. | ||
==== Ressources matérielles ==== | ==== Ressources matérielles ==== | ||
* Vincent Sylvester a vu un rapport d'une grille indiquant que 800 To de données avait été écrites en un peu moins de deux ans, ce qui condamne les [https://fr.wikipedia.org/wiki/SSD SSD]. Il vaut mieux lire et éviter d'écrire dans la base de données pour augmenter la durée de vie des disques. | * Vincent Sylvester a vu un rapport d'une grille indiquant que 800 To de données avait été écrites en un peu moins de deux ans, ce qui condamne les [https://fr.wikipedia.org/wiki/SSD SSD]. Il vaut mieux lire et éviter d'écrire dans la base de données pour augmenter la durée de vie des disques. | ||
* Cela augmente un peu d'utilisation de la mémoire, car il faut lire et stocker temporairement les informations de la base de données pour déterminer l'ensemble des modifications à écrire ou ce qu'il faut supprimer, mais quelques Mo contre des To d'écritures sur le disque est un bon compromis. | * Cela augmente un peu d'utilisation de la mémoire, car il faut lire et stocker temporairement les informations de la base de données pour déterminer l'ensemble des modifications à écrire ou ce qu'il faut supprimer, mais quelques Mo contre des To d'écritures sur le disque est un bon compromis. | ||
==== Tests et retours ==== | |||
* Après un test plus long, Vincent Sylvester espère obtenir des commentaires sur l'efficacité ou non de la nouvelle routine. Même s'il pense qu'elle fonctionnera, on ne sait jamais quel cas extrême pourrait la perturber. Ces tests sont nécessaires. | |||
* Ubit Umarov craint que même avec la nouvelle routine , la base de données doive lire toutes les lignes, les réorganiser et les écrire à nouveau, ce qui pourrait annuler les gains d'efficacité. | |||
* Vincent Sylvester reste optimiste et espère que des tests prolongés montreront comment la nouvelle routine se comporte en termes de performance et d'efficacité | |||
= Informations= | = Informations= | ||
Dernière version du 25 septembre 2025 à 15:29
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
Test d'écriture dans la table primitems
Description
- Vincent Sylvester à créé un fichier binaire avec une nouvelle routine qui lit la base de données pour déterminer ce qu'il faut enregistrer. La routine actuelle supprime tout puis réinsère chaque élément. La différence est assez nette. C'est une conception plus efficace.
- Durée du test : 1 heure. Il est prévu de refaire ce test pendant 24 heures pour observer comment le système réagit quand il s'est stabilisé et quand les utilisateurs interagissent avec lui.
- Graphique du résultat du test :
- Suppression et insertion complètes
- Bruit au redémarrage
- Lire puis remplacer.
_on_eu-cluster2.zetamex.pw3.png)
- Avantage supplémentaire, avec l'ancien routine la base de données doit reconstruire les index à chaque opération de suppression et d'insertion ce qui peut entraîner une perte d'efficacité. La nouvelle routine devrait éviter cela.
Questions à résoudre
- Il reste à définir les critères ou les conditions qui amènent le système à considérer qu'un objet a été modifié pour l'écrire dans la base de données.
- Vincent Sylvester a consulté les journaux d'audit de la base de données et a remarqué que certains éléments y figurent, mais qu'ils n'ont pas été modifiés activement.
- Il n'a pas encore identifié les facteurs ou conditions qui peuvent activer un indicateur (flag) appelé "hasgroupchanged" ainsi que d'autres indicateurs. Ils pourraient expliquer pourquoi certains objets sont considérés comme modifiés alors qu'ils ne le sont pas.
- Il est également nécessaire d'avoir un mécanisme pour retirer les éléments qui ne sont plus présents, ce qui est essentiel pour maintenir l'intégrité de la base de données.
Discussion
Objets non modifiés
- Andrew Hellershanks émet l'hypothèse qu'une persistance intervienne pour écrire les données dans la base de données pour garantir que l'état des objets est correctement enregistré, même en l'absence de modifications détectées.
- D'après sont test local, Vincent Sylvester confirme que c'est ce qui se passe toutes les 10 minutes environ, mais il n'a pas encore réussi reproduire l'enregistrement des données dans la table "primitems".
- Vincent Sylvester suspecte que la réécriture de SetText avec les mêmes données pourrait déclencher des mises à jour inutiles des objets, mais il n'a pas réussi à reproduire ce comportement.De plus, bien que certains objets contiennent des scripts inactifs, ils produisent tout de même des enregistrements.
Amélioration possible
- Techniquement, l'enregistrement pourraient être amélioré en utilisant INSERT ... ON DUPLICATE KEY UPDATE plutôt que REPLACE INTO , mais cela rendrait la requête plus complexe, et Vincent Sylvester ne sais pas comment cela se traduirait côté base de données. Il pourrait en fait y avoir plus de données qu'avec la fonction « REPLACE INTO ».
- Malheureusement, la fonction « REPLACE INTO » effectue toujours une suppression et une insertion avec une reconstruction de l'index, ce qui la rend plus lourde, mais comme la nouvelle routine empêche déjà la réécriture des données existantes, elle réduit considérablement les écritures.
- Il existe peut-être d'autres interactions avec la base de données qui pourraient être améliorées de la même manière, mais chaque chose en son temps.
Ressources matérielles
- Vincent Sylvester a vu un rapport d'une grille indiquant que 800 To de données avait été écrites en un peu moins de deux ans, ce qui condamne les SSD. Il vaut mieux lire et éviter d'écrire dans la base de données pour augmenter la durée de vie des disques.
- Cela augmente un peu d'utilisation de la mémoire, car il faut lire et stocker temporairement les informations de la base de données pour déterminer l'ensemble des modifications à écrire ou ce qu'il faut supprimer, mais quelques Mo contre des To d'écritures sur le disque est un bon compromis.
Tests et retours
- Après un test plus long, Vincent Sylvester espère obtenir des commentaires sur l'efficacité ou non de la nouvelle routine. Même s'il pense qu'elle fonctionnera, on ne sait jamais quel cas extrême pourrait la perturber. Ces tests sont nécessaires.
- Ubit Umarov craint que même avec la nouvelle routine , la base de données doive lire toutes les lignes, les réorganiser et les écrire à nouveau, ce qui pourrait annuler les gains d'efficacité.
- Vincent Sylvester reste optimiste et espère que des tests prolongés montreront comment la nouvelle routine se comporte en termes de performance et d'efficacité
Informations
En souvenir de Mal Burns
- Lyr Lobo rappelle que le 1er octobre aura lieu l'Hypergrid Safari sur Craft pour Mal Burns.
En souvenir de Claudius Utopy
- Vlad et Mininord prévoient un dernier hommage à Claudius le Vendredi 3 Octobre à 21h30 au mémorial des francophones sur opensim: hop://francopholie.fr:8000/Francopholie/797/749/37