Soucis potentiel d'espace disque nécessaire pour la V2

J’ai fais un petit script pour sauver la taille de mes volumes docker chaque jour à la même heure (pour mon 1er serveur Oracle qui host mes 2 serveurs G1v1 et des serveurs G1v2)

Voici les données pour mon cesium-plus-pod G1v1, duniter-pini_duniter G1v1 forgeron, et les différentes versions duniter-v2s:

Volume delta/day MB 1 year MB
cesium-plus-pod_cesium-config/ ,00 ,00
cesium-plus-pod_cesium-data/ 6,94 2.533,53
cesium-plus-pod_cesium-logs/ 1,29 472,35
duniter-pini_duniter_data/ 4,94 1.803,53
duniter-pini_duniter_etc/ ,00 ,00
duniter-v2s-gdev-archive_data-mirror/ 219,76 80.214,12
duniter-v2s-gdev-squid_postgres-data/ 10,00 3.650,00
duniter-v2s-mirror_data-mirror/ 129,53 47.278,24
duniter-v2s-validator_data-validator/ 134,65 49.146,18

Je ne sais pas quelle quantité d’activité est simulée sur le réseau GDev; mais je remarque que dans une situation comme celle ci je vais rapidement avoir un soucis d’espace disque sur mes serveurs qui n’ont que 200GB d’espace disque.

Logiquement, on voit bien que celui dont l’espace disque augmente le plus est le serveur en “archive” avec DUNITER_PRUNING_PROFILE=archive; mais je suis surpris que l’augmentation de taille reste grande également pour celui en mode mirror (sans le paramètre DUNITER_PRUNING_PROFILE) et celui en mode validator avec DUNITER_PRUNING_PROFILE=light

Pour ceux qui veulent les valeurs des 17 derniers jours en détail:
docker-volumes-sizesMB-logs_20241213.ods (17,0 Ko)

Edit: Oups, mauvaise multiplication pour l’année, mais ça reste fort élevé; 80GB par an pour le noeud archive

3 Likes

Les tailles des snapshots Kusama/Polkadot/Rococo parlent d’elles-mêmes : https://snapshots.polkadot.io/, Database sizes | Stakeworld.io. Pour info, Polkadot représente quelque chose comme 350 Go par an. Les nœuds Substrate archives sont un peu gourmands en espace disque.

Cela dit, dans notre cas, avec les commentaires de transaction on-chain, il est clair que l’espace disque sera peut-être un aspect à améliorer à l’avenir.

4 Likes

Je ne voudrais pas être trop alarmiste à ce sujet, mais étant donné qu’il n’est pas possible de repartir d’un Snapshot si un jour on veut sortir les commentaires de TX hors chaîne, une fois que notre BC pèsera 10To, c’est à vie, pour chaque noeud archive.

En fait non, en vrai on pourra toujours décider de rebooter la BC à partir d’un nouveau Snapshot Genesis de l’état actuel sans les commentaires, dans la mesure où les 2/3 des forgerons sont d’accord. Je ne crois pas qu’un runtime upgrade à chaud suffise pour ça, si ?

Il suffira juste de gérer cette migration dans squid, de la même manière que ça a été fait actuellement pour la migration v1/v2.

5 Likes

Concernant les noeuds en mode DUNITER_PRUNING_PROFILE=light; est-ce normal que l’espace disque utilisé continue à augmenter ?

Est-ce qu’ils vont finir par se stabiliser, ou faut-il prévoir une intervention manuelle ou autre pour ne réellement garder que :

  • light: keep only last 256 state blocks and last 14400 blocks (one day duration)

Ou peut-être cela pourrait être lié à l’oracle de distance qui fonctionne sur le même volume docker ?

1 Like

Oui, même en mode pruning light, l’espace disque continuera à augmenter lentement. Je ne sais pas trop si cela a changé du côté du SDK, mais on peut trouver de nombreuses discussions à ce sujet plus ou moins vieilles (Pruning (State and Blocks Pruning) · Issue #4801 · paritytech/polkadot-sdk · GitHub, What Does Disk Usage Go Up Continually, Even More So in Pruned Mode? · paritytech/substrate · Discussion #10948 · GitHub, Block header pruning - Tech Talk - Polkadot Forum).

On le voit aussi bien sur les réseaux Polkadot :

3 Likes

Je suis d’accord, c’est un sujet important et que je n’ai pas assez creusé pour l’instant. J’aimerais bien avoir des informations de profiling pour voir qu’est-ce qui prend de la place et voir s’il y a des réglages pour diminuer l’impact. Je demanderai à @elois s’il a un avis là dessus.

Si la simple production de blocs constitue une part importante de la consommation de disque, on pourrait envisager de ralentir la production de bloc à 9s, ou 12s. Ça resterait une augmentation significative par rapport à 5 minutes, mais il faudrait peut-être revoir l’UX des appli pour afficher un “ok” à la diffusion dans le réseau plutôt que l’intégration dans un bloc, sachant que les chances d’inclusions restent très élevées quand le réseau est en bonne santé.

J’ai créé la #267 pour suivre ça.

3 Likes

Traduction du ticket Profile disk use (#267) · Issues · nodes / rust / Duniter v2S · GitLab

Pour se donner un peu de visibilité sur l’espace disque nécessaire à un nœud Duniter (ce qui concerne surtout les nœuds archive et forgeron), j’ai extrapolé l’espace disque nécessaire pour un nœud en me basant sur les données du réseau GDev actuellement déployé.

Méthode

Afin de fournir une estimation des exigences de stockage, j’ai surveillé l’espace disque utilisé par un nœud archive (target/release/duniter --chain=gdev --blocks-pruning=archive --state-pruning=archive). J’ai enregistré le numéro du bloc importé ainsi que l’espace disque occupé par le nœud toutes les 30 secondes, en maintenant ce processus de manière régulière pendant plusieurs semaines.

Résultats

La Figure 1 illustre la relation entre le nombre de blocs importés et l’utilisation correspondante de l’espace disque. Les données montrent une augmentation non linéaire du stockage durant la période d’observation. À des intervalles de temps plus courts, cette augmentation se manifeste par des paliers discrets.

Figure 1 : Nombre de blocs versus utilisation de l'espace disque pendant la période observée.

La Figure 2 illustre la distribution de la durée de ces paliers en nombre de blocs. La durée des paliers est fortement variable, avec une prédominance notable autour de 100 blocs (soit environ 10 minutes).

Figure 2 : Distribution des durées des paliers.

La Figure 3 présente l’évolution de l’utilisation de l’espace disque du nœud, montrant à la fois les données mesurées et la courbe ajustée. Pour modéliser la croissance, les données ont été ajustées à l’aide d’un polynôme de second degré sans terme constant, la fonction continue la plus simple qui suppose que l’espace disque au bloc zéro est proche de zéro et qui représente de manière adéquate le comportement observé. Cette fonction met en évidence l’accélération des besoins en stockage à mesure que la blockchain évolue.

Figure 3 : Évolution de l'utilisation de l'espace de stockage depuis le démarrage du nœud, ajustée à l'aide d'un polynôme de second degré.

Prédiction

Je n’ai pas encore mené d’investigation détaillée sur l’augmentation par paliers du stockage. Bien que ce phénomène n’ait pas d’impact direct sur la croissance globale de la taille du stockage, sa cause reste incertaine. Il est probable qu’il résulte soit d’une suppression différée des fichiers au niveau de la base de données/système, soit d’une compression quasi-périodique des structures de données intermédiaires au niveau du nœud. Pour mieux comprendre d’où provient ce comportement, l’enregistrement de données provenant d’un nœud fonctionnant avec RocksDB pourrait apporter plus éclaircissements.

Sur la base des résultats observés, il est évident que l’utilisation de l’espace disque suit une tendance non linéaire. Les données collectées, bien que limitées, peuvent être ajustées à l’aide d’un polynôme de second degré. La Figure 4 présente l’utilisation projetée de l’espace disque selon cet ajustement polynomial, accompagnée des marges d’erreur calculées à partir de la matrice de covariance de l’ajustement. Cela permet d’obtenir une prévision préliminaire des besoins en stockage, tout en soulignant l’incertitude inhérente du modèle et au jeu de données restreint.

Figure 4 : Prédiction de l'utilisation de l'espace disque.

Les observations du réseau Polkadot indiquent qu’un nœud archive nécessite environ 2 765 GiB de stockage après 4,71 ans de fonctionnement (source : stakeworld.io, Polkadot wiki). En revanche, notre réseau reste largement inactif, avec une croissance du stockage principalement due aux opérations nécessaires pour forger des blocs vides et assurer les fonctions de base du réseau, telles que les DUs et les certifications.

Compte tenu de ces conditions, notre prédiction de 500 ± 250 GiB de stockage après 4 ans (bien que reposant sur des données limitées) semble plausible par rapport à des réseaux très utilisés comme Polkadot. Cette estimation fournit un repère approximatif des futurs besoins en stockage, notamment lorsqu’elle est comparée à des réseaux de longue durée tels que Polkadot et Kusama, où un niveau d’activité plus élevé contribue de manière significative à la croissance du stockage.

Conclusion

Les données actuellement disponibles fournissent un modèle avec un pouvoir prédictif modéré pour les 2 premières années, mais limité au-delà. Cependant, elles offrent une estimation raisonnable, notamment lorsqu’elles sont combinées avec les tendances de stockage des nœuds Polkadot. Ces données suggèrent qu’au cours des 3 à 4 prochaines années, les besoins en stockage ne dépasseront probablement pas 1 TiB. Cela s’inscrit plutôt bien dans les tendances actuelles de taille et de prix des SSD pour des exigences matérielles modestes.

Pour affiner ces prédictions, une surveillance continue de l’utilisation de l’espace disque d’un nœud sera essentielle, surtout à mesure que l’activité du réseau augmente. L’augmentation du volume des transactions, en particulier avec le stockage on-chain des commentaires de transactions, pourrait avoir un impact significatif sur les besoins futurs en stockage. En mettant régulièrement à jour le modèle, nous pourrons fournir des prévisions plus précises à mesure que le réseau et ses dynamiques évoluent.

6 Likes

Merci pour ces données très détaillées :slight_smile:

Petite erreur ici (=> GiB et pas TiB):

Et est-ce qu’il serait possible d’analyser également un noeud SMITH avec le minimum possible d’ “archive” ?

La raison de ma demande est que si l’on n’arrive pas à rester sous une certaine taille dans la durée, très peu de personnes seront en mesure de garder un noeud SMITH !

Pour mon cas personnel ; mes serveurs Oracle gratuits offrent seulement 200GiB de stockage.

Edit: J’ajoute la mise à jour de mes données d’usage disque Docker pour les serveurs.

docker-volumes-sizesMB-duniterV2s_logs_20250212.ods (25,1 Ko)

On remarque que cela continue à augmenter pour duniter-v2s-validator_data-validator qui est configuré avec pruning profile “light”

    environment:
      - DUNITER_CHAIN_NAME=gdev
      - DUNITER_VALIDATOR=true
      - DUNITER_PRUNING_PROFILE=light

(Il faudrait peut-être faire un graphe avec les données, il est possible de l’augmentation de taille diminue avec le temps)

J’ai rapidement fait un graphe pour les données du validator

1 Like

C’est corrigé, merci.

Un nœud Smith peut être lancé à partir d’une base de données réduite. Dans le cas de Polkadot, elle fait en ce moment 520 GiB, soit environ 81% de moins que l’archive. Ça donne déjà un ordre d’idée d’une borne maximale, donc je pense qu’on va être loin des 200 GiB avant quelques années pour ce type de nœud.

Quand on regarde (encore une fois) chez Polkadot, on voit que l’augmentation de la taille, que ce soit des archives ou des db réduites, suit la même tendance, avec simplement une pente moins forte.

Dans tous les cas, je pense qu’il est utile que quelques personnes surveillent leurs nœuds. Ainsi, on pourra anticiper avant le lancement de la G1. Sachant que l’augmentation actuelle est en grande partie due au fonctionnement de base du réseau, on peut très bien ralentir le rythme de 10 blocs par minute à 7 (voire 5 pour être très conservateur), ce qui permettrait de diminuer d’un tiers (ou de moitié) l’accumulation d’espace disque nécessaire sur un temps donné.

1 Like

J’ai beau y réfléchir, je ne vois pas bien l’utilité aurait un nœud archive sur le réseau. A part pour des investigations poussées, par exemple pour débusquer un bug, je ne vois pas.

Autrement dit si c’est une utilité de niche, 10To dans ce cas ne sont probablement pas un gros problème.

Pour que les indexers puissent indexer.

Les indexeurs n’indexent pas juste les events présents dans les blocs ?

Si, seul les indexer stock tous les events depuis le début non ?

Ca me rappel cette discussion du coup je ne suis plus bien sûr: Élagage de l'état, élagage des blocs, noeuds archive et miroir - #2 by poka

Ah oui l’indexeur a besoin de reparcourir l’intégralité des events, et pour ça le plus “bourrin” consiste à avoir un nœud archive qui n’élague pas les events (qui sont dans le storage, donc élagués avec les blocs).

Ok, m’enfin d’une part cet algo “bourrin” pourrait être plus fin, mais d’autre part 1 seul nœud archive suffit en-dehors du fil de l’eau, car dans ce dernier cas les nœuds archive ne sont pas nécessaires. Et on peut à tout moment remonter de zéro un nouveau nœud archive si besoin.

Ah OUé !! Quand même…

Ca fait beaucoup pour juste assurer (+/-) entre 2 clefs de temps en temps dans l’espace relatif de leurs interactions comptables par rapport à l’ensemble des utilisateurs.

C’est cool si on peut faire des optimisations et des “reconciliations comptables” avant le To de données… J’espère ne pas devoir dédier ma station uniquement à Duniter, j’aimerai bien avoir de la place pour NextCloud et IPFS :wink:

Peut-être avec le protocole “NOSTR” et des synchro façon negentropy pourquoi pas aussi mapper la WoT à l’infra et au territoire

Je suis d’accord que le nœud archive est de niche : il sert uniquement à une analyse approfondie de la chaîne. Je ne pense pas que 1 TiB soit prohibitif pour que quelques utilisateurs en fassent tourner un.

Un nœud Substrate peut repartir d’une snapshot de la base de données (d’une source sûre) pour aller plus vite. Il y a peut-être moyen de faire la même chose avec l’indexeur ; cela éviterait également un temps de synchronisation non négligeable.

2 Likes