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…
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.
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.
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é.
