Bonsoir,
Mon nœud a mis 9h à “appliquer” la blockchain, à massacrer mon disque dur tout en restant à moins de 5% du CPU (un i5), et pendant que le serveur tourne le disque continue à crier à l’aide…
Pourquoi ne pas utiliser mes 8 Go de RAM qui ne m’ont jamais servi ?
Voici une idée pour économiser le dd si on a assez de RAM :
cd ~/.config
mv duniter duniter.bak # renommer le dossier duniter
# monter /dev/shm si ce n'est pas fait automatiquement
cp -r duniter.bak /dev/shm/duniter # le copier dans la mémoire partagée
ln -s -d /dev/shm/duniter duniter # faire un lien vers le dossier en mémoire
# puis lancer duniter
Et quand on arrête la machine, il suffit de sauvegarder le dossier dans le dd :
# arrêter duniter
cp -r /dev/shm/duniter duniter.bak2 # copier de la mémoire vers le dd
rm -r duniter.bak # supprimer l'ancienne sauvegarde après la copie pour en avoir toujours au moins une en sécurité
J’ai testé ça, pour l’instant ça a l’air de fonctionner, juste le bruit du disque dur en moins.
Est-ce que vous pensez que c’est une bonne idée ? Est-ce que le nombre d’écritures sur le disque est vraiment inférieur puisqu’il faut toujours sauvegarder l’intégralité du dossier dans le dd à chaque arrêt ?
Et si c’est une bonne idée, ça pourrait être implémenté dans Duniter ?
Bonsoir @tuxmain, il me semble que la prochaine version de Duniter (la 1.7) utilisera justement la RAM pour la sync, ce qui devrait la rendre considérablement plus rapide
En tout cas c’est déjà ce que j’ai appliqué dans Durs (réimplémentation de Duniter en Rust) et ça “applique” la blockchain en moins de 10 secondes.
Bref, c’est déjà la direction qu’on a pris dans les 2 implémentations
Oui il faudra, perso j’ai pour objectif que Durs puisse tourner sur ARM avec 1Go de RAM.
Mais pour ça il faudra qu’on fasse évoluer le protocole de façon a ne pas garder tout les blocks sur tout les nœuds, c’est déjà prévu dans notre roadmap : (étape “Merklarisation des données de blocs”) : Évolutions du protocole vers v11, v12, etc
Quand est-ce qu’on pourra tester ça ? car j’avoue que passer en partie en RAM sous banana Pi (2GB) serait très bienvenu ! Moi c’est pas le HD que ça me massacre mais la micro-SD, beaucoup moins durable
Pour Duniter dés la 1.7, je suppose que @cgeek vas nous la présenter pour les rml12 ? Il faudra du temps avant qu’elle soit poussée en stable mais tu peut faire parti des testeurs si tu souhaite l’utilisée au plus tôt
Avec 2 Go de RAM ça devrait déjà être possible temporairement, la blockchain fait moins de 400 Mo avec Duniter.
Il reste combien de libre avec Duniter qui tourne ?
Faut voir, peut-être la semaine prochaine. Je suis encore en train de peaufiner la couche d’accès aux données, et mon constat c’est que la nouvelle couche est déjà suffisante en termes de performances.
Je proposerai toutefois l’option “synchro en RAM”, pour la liberté de chacun. On n’a pas tous les mêmes configurations à déployer, et je sais à qu’une carte SD peut vraiment se montrer sous-efficiente sur certains traitements.
Pour info : la synchro de la Ğ1 est passée sans encombres sur mon Raspberry PI 3, en 30 minutes, sans utiliser l’option de synchro en mémoire.
Le Raspi était toutefois vierge, je ne sais pas si ça passerait avec d’autres services installés. Il faudra faire d’autres mesures, je compterai sur vous pour cela quand la release sera prête
Lol, je t’avoue que pour mon rasp comme pour mon banana, je comprends pas tout ce que je fais. Et 30 minutes la synchro, là tu me troue le *** car moi c’est au moins 2 jours (en reset data) !
Mais passer en RAM a le mérite d’épargner le HD ou la SD, et ça c’est bien
