Derzeit läuft Geth 1.8 auf Ubuntu 17.10 auf einer SSD. Jedes Mal, wenn ich Geth starte, wird es immer synchronisiert, bis es die letzten 65 Blöcke erreicht, wo es einfach hängt und so aussieht, als ob es beim Herunterladen der Kettenstruktur hängen bleibt.
Habe so angefangen:geth --cache=4192
> eth.syncing
{
currentBlock: 5111107,
highestBlock: 5111172,
knownStates: 334023,
pulledStates: 319685,
startingBlock: 5105310
}
Startprotokolle:
INFO [02-17|22:47:12] Maximum peer count ETH=50 LES=0 total=50
INFO [02-17|22:47:12] Starting peer-to-peer node instance=Geth/v1.8.0-stable/linux-amd64/go1.8.3
INFO [02-17|22:47:12] Allocated cache and file handles database=/media/solidity/Data/mainnet/geth/chaindata cache=3144 handles=512
INFO [02-17|22:47:22] Initialised chain configuration config="{ChainID: 1 Homestead: 1150000 DAO: 1920000 DAOSupport: true EIP150: 2463000 EIP155: 2675000 EIP158: 2675000 Byzantium: 4370000 Engine: ethash}"
INFO [02-17|22:47:22] Disk storage enabled for ethash caches dir=/media/solidity/Data/mainnet/geth/geth/ethash count=3
INFO [02-17|22:47:22] Disk storage enabled for ethash DAGs dir=/home/solidity/.ethash count=2
INFO [02-17|22:47:22] Initialising Ethereum protocol versions="[63 62]" network=1
Der Teil "letzte 65 Blöcke" ist normal. Als der „Fast Sync“-Modus zum ersten Mal in eingeführt wurdeeth/63 , war es sogar noch mehr.
Ich schlage vor, dass Sie sich diese PR ansehen, um eine allgemeine Beschreibung dessen zu erhalten, was geth's --syncmode=fasttatsächlich tut.
Kurz gesagt: Es werden nicht alle Blöcke bis zum Kopf heruntergeladen, damit Kettenreorgs ordnungsgemäß gehandhabt werden können - insbesondere, da der Knoten keinen früheren "Status-Snapshot" hat, auf den er zurückgreifen kann, wenn in der Zeit, in der Sie es tun , ein Reorg stattfindet . erneute Synchronisierung, früher als der Pivot-Block, mit dem Sie schnell synchronisieren.
Wie in den Kommentaren erwähnt , muss der Knoten nach dem Synchronisieren von Blöcken mit dem Pivot auch den Status am Pivot synchronisieren - was heutzutage eine Weile dauert, vielleicht sogar länger als das Synchronisieren der Blöcke.
Leicht OT:
Wenn die Synchronisierung von Blöcken auf langsamen Maschinen (Netzwerk- oder Speicher-IO) zu lange dauert, gibt es möglicherweise keine Peers, die tatsächlich noch einen Snapshot davon haben, wenn ein Knoten mit der Synchronisierung des Status beginnen würde. (Denken Sie daran, dass das Netzwerk nicht nur aus gethPeers besteht; einige Knoten haben möglicherweise eine radikal andere Sicht auf die Beibehaltung des historischen Zustands – und was als „historisch“ zu betrachten ist.)
Ein häufiger Fehler an dieser Stelle ist das Neustarten der Synchronisierung nach dem Löschen der Datenbank . Versuchen Sie es zuerst ohne das! Andernfalls müssen Sie die Blöcke erneut herunterladen, was wahrscheinlich (immer wieder) auf dasselbe Problem stößt.
Ismael
hextet