Comment améliorer bitcoin-qt lors du téléchargement de blockchain ? (très technique, vues de développement appréciées)
Réponse courte et simple à mon problème initial concernant le téléchargement de la blockchain : vous pourriez avoir besoin d’un meilleur matériel ! 🙂
En résumé, bitcoin-qt est prêt à l’emploi. Alors ne tâtonnez pas. Sauf si vous en avez vraiment besoin.
L’élagage économise de l’espace disque mais augmente les E/S disque. L’augmentation de dbcache peut aider, mais pas tant pour l’élagage. Les deux peuvent être effectués dans la fenêtre de configuration. Ainsi, pas besoin de modifier bitcoin.conf.
)
Ayant cela hors de mon chemin, plongeons dans ma « vraie » question.
nous avons trois domaines à considérer.
Côté entrée À première vue, il semble que j’ai eu des problèmes de connexion aux nœuds réactifs. En y regardant de plus près, j’ai trouvé que le côté envoi n’était jamais vraiment un problème.
Le comportement d’envoi des nœuds en moyenne sur une longue période m’a fait distinguer trois types principaux. Quelques-uns envoient des Mo, certains quelques Ko et beaucoup seulement 150 octets puis abandonnent
Au fil du temps, les nœuds réactifs réduisent leur débit de données.
Les données arrivent généralement en masse. Tous les nœuds envoient en parallèle de nombreux Mo/s puis s’arrêtent pendant plusieurs minutes. Alors que mon CPU et mon disque sont constamment occupés. Il semble donc qu’ils remplissent une file d’attente d’entrée. Il s’agit généralement d’un comportement habituel pour les systèmes en file d’attente. Ils pompent. C’est pourquoi vous avez des tampons. On dirait que l’augmentation des tampons n’aidera pas sur ma machine, car il y a déjà beaucoup de marge.
L’envoi à des débits de données élevés et le ralentissement dans le temps sont logiques pour que les nœuds répartissent la charge sur d’autres nœuds. Du point de vue des clients, il s’agit également d’un comportement préférable. Bien que mon point de vue en tant qu’utilisateur soit que bitcoin-qt peut améliorer sa stratégie de chute, ne pas déranger les nœuds qui ont fait leur juste part et se concentrer davantage sur des nœuds encore très réactifs.
L’envoi de Ko, même quelque peu erratique à des débits de données faibles, n’est pas vraiment utile. Étant donné que dans un réseau libre, vous ne pouvez pas dire à un nœud quoi faire, les clients ont besoin d’une stratégie pour supprimer ces nœuds tôt.
En bref : Oui, techniquement, il y a place à l’amélioration. Mais est-ce que ça vaut le coup ?
Côté traitement je dirais que tout va bien. Ni la mémoire ni le processeur ne sont problématiques.
Côté sortie, les E/S disque sont un problème, du moins pour moi. Comme l’a souligné Pieter, l’élagage empêche une mise en cache optimale. Je suis réticent à juger sur ce sujet sans une compréhension approfondie. Mais ma première approche serait de réduire le nombre de fichiers impliqués.
Un grand merci à Pieter et Murch pour leur réponse rapide. Beaucoup aidé !
Commentaires et corrections très appréciés !
