New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What is the upper bound of "imported new state entries"? #14647

Closed
sonulrk opened this Issue Jun 18, 2017 · 120 comments

Comments

Projects
None yet
@sonulrk

sonulrk commented Jun 18, 2017

System information

Geth version: 1.6.5
OS & Version: Windows 7 x64
geth Command: geth --fast --cache 8192

Expected behaviour

Geth should start in full mode.

Actual behaviour

After nearing the current block geth is continuously "imported new state entries".

Steps to reproduce the behaviour

Currently running since 10 days.

Geth console info

eth.blockNumber
6
eth.syncing
{
currentBlock: 3890742,
highestBlock: 3890893,
knownStates: 17124512,
pulledStates: 17105895,
startingBlock: 3890340
}

Backtrace

INFO [06-18|10:10:31] Imported new state entries count=384 elapsed=22.001ms processed=17118951 pending=24263
INFO [06-18|10:10:32] Imported new state entries count=384 elapsed=33.001ms processed=17119335 pending=23819
INFO [06-18|10:10:33] Imported new state entries count=384 elapsed=111.006ms processed=17119719 pending=23875
INFO [06-18|10:10:34] Imported new state entries count=384 elapsed=131.007ms processed=17120103 pending=23855
INFO [06-18|10:10:35] Imported new state entries count=384 elapsed=116.006ms processed=17120487 pending=23978
INFO [06-18|10:10:36] Imported new state entries count=384 elapsed=134.007ms processed=17120871 pending=24186
INFO [06-18|10:10:38] Imported new state entries count=384 elapsed=305.017ms processed=17121255 pending=27727
INFO [06-18|10:10:42] Imported new state entries count=384 elapsed=448.025ms processed=17121639 pending=33614
INFO [06-18|10:10:46] Imported new state entries count=384 elapsed=441.025ms processed=17122023 pending=39642
INFO [06-18|10:10:48] Imported new state entries count=384 elapsed=44.002ms processed=17122407 pending=39170
INFO [06-18|10:10:52] Imported new state entries count=384 elapsed=427.024ms processed=17122791 pending=45142
INFO [06-18|10:10:55] Imported new state entries count=384 elapsed=473.027ms processed=17123175 pending=51166
INFO [06-18|10:10:58] Imported new state entries count=384 elapsed=448.025ms processed=17123559 pending=57128
INFO [06-18|10:11:01] Imported new state entries count=384 elapsed=444.025ms processed=17123943 pending=63129
INFO [06-18|10:11:04] Imported new state entries count=384 elapsed=441.025ms processed=17124327 pending=69173
INFO [06-18|10:11:04] Imported new state entries count=1 elapsed=0s processed=17124328 pending=69172
INFO [06-18|10:11:07] Imported new state entries count=384 elapsed=442.025ms processed=17124712 pending=75182
INFO [06-18|10:11:10] Imported new state entries count=384 elapsed=470.026ms processed=17125096 pending=81186
INFO [06-18|10:11:11] Imported new state entries count=384 elapsed=335.019ms processed=17125480 pending=81736
INFO [06-18|10:11:14] Imported new state entries count=384 elapsed=440.025ms processed=17125864 pending=87718
INFO [06-18|10:11:15] Imported new state entries count=384 elapsed=140.008ms processed=17126248 pending=87812
INFO [06-18|10:11:16] Imported new state entries count=384 elapsed=31.001ms processed=17126632 pending=87226
INFO [06-18|10:11:18] Imported new state entries count=384 elapsed=88.005ms processed=17127016 pending=87040
INFO [06-18|10:11:19] Imported new state entries count=384 elapsed=39.002ms processed=17127400 pending=86803
INFO [06-18|10:11:20] Imported new state entries count=384 elapsed=36.002ms processed=17127784 pending=86585
INFO [06-18|10:11:23] Imported new state entries count=1 elapsed=0s processed=17127785 pending=86272
INFO [06-18|10:11:23] Imported new state entries count=384 elapsed=1.610s processed=17128169 pending=86271
INFO [06-18|10:11:25] Imported new state entries count=384 elapsed=143.008ms processed=17128553 pending=87792
INFO [06-18|10:11:28] Imported new state entries count=384 elapsed=183.010ms processed=17128937 pending=90117
INFO [06-18|10:11:28] Imported new state entries count=1 elapsed=1ms processed=17128938 pending=90120
INFO [06-18|10:11:28] Imported new state entries count=1 elapsed=0s processed=17128939 pending=90118
INFO [06-18|10:11:29] Imported new state entries count=384 elapsed=102.005ms processed=17129323 pending=90022
INFO [06-18|10:11:30] Imported new state entries count=384 elapsed=184.010ms processed=17129707 pending=92320
INFO [06-18|10:11:32] Imported new state entries count=384 elapsed=185.010ms processed=17130091 pending=94665
INFO [06-18|10:11:34] Imported new state entries count=384 elapsed=187.010ms processed=17130475 pending=97053
INFO [06-18|10:11:36] Imported new state entries count=384 elapsed=194.011ms processed=17130859 pending=99550
INFO [06-18|10:11:38] Imported new state entries count=384 elapsed=183.010ms processed=17131243 pending=101954
INFO [06-18|10:11:40] Imported new state entries count=384 elapsed=202.011ms processed=17131627 pending=104395
INFO [06-18|10:11:42] Imported new state entries count=384 elapsed=196.011ms processed=17132011 pending=106904
INFO [06-18|10:11:44] Imported new state entries count=384 elapsed=186.010ms processed=17132395 pending=109176
INFO [06-18|10:11:47] Imported new state entries count=384 elapsed=184.010ms processed=17132779 pending=111554
INFO [06-18|10:11:47] Imported new state entries count=2 elapsed=184.010ms processed=17132781 pending=111554
INFO [06-18|10:11:48] Imported new state entries count=384 elapsed=34.002ms processed=17133165 pending=110760
INFO [06-18|10:11:50] Imported new state entries count=384 elapsed=193.011ms processed=17133549 pending=113172

@ghost

This comment has been minimized.

ghost commented Jun 28, 2017

Yes .. same exact effect
Command is: geth --syncmode=fast --cache=4096 console

@fjl

This comment has been minimized.

Contributor

fjl commented Jun 28, 2017

Please try geth v1.6.6.

@n0-m4d

This comment has been minimized.

n0-m4d commented Jun 30, 2017

in my case v1.6.6 does not fix it

@pebwindkraft

This comment has been minimized.

pebwindkraft commented Jul 2, 2017

same here, described detailed status here:
#14571

@egortsaryk9

This comment has been minimized.

egortsaryk9 commented Jul 4, 2017

The same for me for --testnet (ropsten) on Mac OS. The geth version is 1.6.6.
I'm running:
geth --testnet --syncmode "fast" --rpc --rpcapi db,eth,net,web3,personal --cache=1024 --rpcport 8545 --rpcaddr 127.0.0.1 --rpccorsdomain "*" --bootnodes "enode://20c9ad97c081d63397d7b685a412227a40e23c8bdc6688c6f37e97cfbc22d2b4d1db1510d8f61e6a8866ad7f0e17c02b14182d37ea7c3c8b9c2683aeb6b733a1@52.169.14.227:30303,enode://6ce05930c72abc632c58e2e4324f7c7ea478cec0ed4fa2528982cf34483094e9cbc9216e7aa349691242576d552a2a56aaeae426c5303ded677ce455ba1acd9d@13.84.180.240:30303"
and when it comes near to latest blocks (at https://ropsten.etherscan.io/) it continuously "imports new state entries". If I restart the cmd above it fetches most recent blocks but never reach latest ones.

@porfavorite

This comment has been minimized.

porfavorite commented Jul 8, 2017

same here... the geth is 1.6.6, running geth --testnet --fast --cache=1024

@adhicl

This comment has been minimized.

adhicl commented Jul 11, 2017

I am in same state after a week using geth --fast --cache=1024. Anyone knows what should I do right now?

@thecopy

This comment has been minimized.

thecopy commented Jul 17, 2017

Same situation on testnet. OSX, geth 1.6.7-stable-ab5646c5. Started with --fast and --cache 1500

@sonulrk

This comment has been minimized.

sonulrk commented Jul 17, 2017

What I could understand from this geth fast mode problem is that:

  1. You must use Quad core processor with 4 gb or more RAM
  2. You must use SSD instead of HDD
  3. Your internet connection must be at least 2mbps or more and reliable.
    If all above are checked then you should try geth. Using geth in full mode you would most probably synced in a week or two max. In fast mode it depends on your luck but you are most probably synced in 2-3 days or never.
@clowestab

This comment has been minimized.

clowestab commented Aug 23, 2017

Encountering similar issues. Geth --fast sync does not sync, let alone fast.

Using 1.6.7-stable on Ubuntu, and it gets within 100 blocks and then endlessly imports state entries.

@alfkors alfkors referenced this issue Aug 31, 2017

Closed

OSX Mist sync #15059

@alfkors

This comment has been minimized.

alfkors commented Sep 1, 2017

@clowestab did you ever get it to sync?

@kashkalik

This comment has been minimized.

kashkalik commented Sep 2, 2017

Having same issue. Also using ubuntu, and geth endlessly syncs.

@mboehler

This comment has been minimized.

mboehler commented Sep 7, 2017

I am having the same issue. Has anyone been able to solve this problem?

@brennino

This comment has been minimized.

brennino commented Sep 8, 2017

Same problem here, I run geth with 1024 cache and fast syncing three days ago and, after reaching the last block number one day ago, it had never stopped the "Imported new state entries" state.

During this "state entries" phase, however, my balance changed from 0 to the correct value and the block number reported changed from 0 to the a number near the highestBlock value.

This is geth version on my ubuntu machine:

Geth
Version: 1.6.7-stable
Git Commit: ab5646c
Architecture: amd64
Protocol Versions: [63 62]
Network Id: 1
Go Version: go1.8.1
Operating System: linux
GOPATH=
GOROOT=/usr/lib/go-1.8

and this is the result now every half second:
...
INFO [09-08|10:05:34] Imported new state entries count=11 flushed=7 elapsed=216.807ms processed=25170515 pending=1852 retry=1 duplicate=5293 unexpected=6261
INFO [09-08|10:05:34] Imported new state entries count=2 flushed=5 elapsed=521.989µs processed=25170517 pending=1847 retry=0 duplicate=5293 unexpected=6261
INFO [09-08|10:05:34] Imported new state entries count=7 flushed=1 elapsed=263.738ms processed=25170524 pending=1862 retry=2 duplicate=5293 unexpected=6261
INFO [09-08|10:05:34] Imported new state entries count=2 flushed=4 elapsed=6.934ms processed=25170526 pending=1859 retry=0 duplicate=5293 unexpected=6261
INFO [09-08|10:05:34] Imported new state entries count=1 flushed=0 elapsed=27.828ms processed=25170527 pending=1861 retry=1 duplicate=5293 unexpected=6261
INFO [09-08|10:05:34] Imported new state entries count=5 flushed=5 elapsed=19.440ms processed=25170532 pending=1860 retry=0 duplicate=5293 unexpected=6261
...

this is the result of eth.syncing and other geth tools:

eth.syncing
{
currentBlock: 4249131,
highestBlock: 4250814,
knownStates: 25172364,
pulledStates: 25170517,
startingBlock: 0
}

net.peerCount
25

eth.blockNumber
4244762

The ether balance of my wallet is not 0 and is reported correcly and updated to the last transaction made one day ago.

How long is this state supposed to last?

@brennino

This comment has been minimized.

brennino commented Sep 8, 2017

Another information, my .ethereum folder size is currently 41 GB, maybe a little too large for a right fast sync.

@sonulrk

This comment has been minimized.

sonulrk commented Sep 8, 2017

I think never.

@brennino

This comment has been minimized.

brennino commented Sep 8, 2017

UPDATE: I stopped geth with CTRL-D and reopen it. Now it seems that the "Imported new state entries" phase halted and geth is working correctly updating only new blocks.
It seems that the problem is that fast sync continue forever to download states and is not aware that the blockchain has already in a right, consistent state.

So, for now until the issue is solved this is my advise:

  • Start geth fast sync
  • wait until the command eth.syncing report a currentBlock near the highestBlock
  • After that, every few hours run the command: eth.blockNumber ... firstly it returns probably 0 but continue to wait.
  • When eth.blockNumber returns a value different from 0 and near the currentBlock value close geth with (CTRL-D or with the command "exit" so it can close correclty and under control) and wait until the program closes in the right way and your operating system shell comes back
  • Reopen geth with fast option. You will see the warning "Blockchain not empty, fast sync disabled"... this is the correct behavior, is telling you that fast sync has been finished.
  • Now the "Imported new state entries" messages disappear and you just see this messages every few seconds:
    INFO [09-08|21:12:06] Imported new chain segment blocks=1 txs=131 mgas=5.379 elapsed=13.855s mgasps=0.388 number=4251422 hash=697652…d85ce8

Now your problem has been solved and probably geth avoid to download a lot of states, reducing the hard disk space taken by geth too.

This is valid until the issue will be solved and geth will become aware when the blockchain is correctly synced.

This is my experience, maybe work, maybe not. For me it worked.
Hope this helps,
Marco

@sonulrk

This comment has been minimized.

sonulrk commented Sep 8, 2017

Congrats but I had run it for more than 8 hours and eth.blockNumber had shown 6 always. I have to change to parity to sync the blockchain.
Edit: Fast sync worked at first run only on consecutive run you have to run in full mode or geth automatically give warning "Blockchain not empty, fast sync disable" and continue with full mode.

@brennino

This comment has been minimized.

brennino commented Sep 9, 2017

I think you have just to wait until eth.blockNumber shows a number near currentBlock before close it and start it again.
I forget to tell to remove old blockchains before starting the task I told before.
Yes, fast sync can be used with an empty blockchain and only the first time.
The command for clear the whole blockchain is "geth removedb" on the operating system shell, it removes everything has been downloaded before.
After that you are able to start a fast sync again from an empty blockchain and follow the procedure I told in my prev post hoping it works.

I'm not a geth developer, I just use it so I can't solve the problem or tell you what it does internally or why the command returns you "6" and what you have to do, but it seems that it downloads a lot of states and, when it finds the head state it's able to build the full blockchain. For me this happened when geth.syncing showed a "knownStates" near : 20.000.000 but it can happen before or after.

During my test, after fast sync finished to download all the blocks headers, it takes more than 24 hours more for having eth.blockNumber = 4244762 . I run geth on a server in with a band of 100 Mb/s.

When it showed to me "0" I let it doing the work and after 24 hours I see the command returns 4244762. I haven't tried to run the command in the middle so I don't know if the command returns other numbers before reaching the last block.

I have never used parity but is seems good and use less disk space than geth so it worth a try.
Maybe some geth dev can make things more clear.

@fjl

This comment has been minimized.

Contributor

fjl commented Sep 10, 2017

We believe this is fixed on the master branch. Fast sync takes a while (especially with the mainnet), but will terminate eventually.

@vincentvc

This comment has been minimized.

vincentvc commented Sep 12, 2017

@brennino
My eth.blockNumber shows 0 after almost several days sync. I am wondering whether the fast sync will fail if I stop and restart the sync process in middle for several times.

@manicprogrammer

This comment has been minimized.

Contributor

manicprogrammer commented Sep 12, 2017

@vincentvc fast sync in geth only works when the database is empty thus you get one chance to fast sync and then it will be the full sync after that [STATED IN ERROR THE FOLLOWING- THIS IS INCORRECT AS POINTED OUT BY FJL: thus yes if you stop and restart anytime before that first fast sync finishes you won't do a fast sync from that point.] My experience with the scenario listed here was two fold. I used the latest build off of main and I made sure I had my database on an SSD. doesn't seem like the SSD vs HDD thing would matter so much but in my experience, until I put it on the SSD I could never get that first sync to finish up - not to say that is true for everyone just my experience.

@skarn01

This comment has been minimized.

skarn01 commented Sep 13, 2017

I'm having the same problem, continuous imported state I'm currently trying as @brennino says and will come back with result later... currently 350k states processed

here some info :

> eth.syncing
{
  currentBlock: 4269853,
  highestBlock: 4270000,
  knownStates: 357664,
  pulledStates: 348163,
  startingBlock: 4268019
}

net.peerCount 10

eth.blockNumber 0
update : almost 24h later here's the number
blockNumber : 0

eth.syncing
{
currentBlock: 4270728,
highestBlock: 4270793,
knownStates: 6879452,
pulledStates: 6875584,
startingBlock: 4268019
}

imported state still going, gonna check back tomorow...

@brennino

This comment has been minimized.

brennino commented Sep 14, 2017

hi @skarn01 I don't know if this happen only to me but when I start fast sync with an empty block chain starting block always shows 0. You can see my eth.syncing on my previous post that I report here:

eth.syncing
{
currentBlock: 4249131,
highestBlock: 4250814,
knownStates: 25172364,
pulledStates: 25170517,
startingBlock: 0
}

Maybe something wrong happen during fast sync or you close geth before eth.blockNumber says a number near last block. Blockchain sync is really time consuming and you haven't to stop fast sync until finishes or eth.blockNumber != 0 and near highestBlock.

What can I tell for helping you... it seems you are not starting fast sync from an empty block chain so if I'm in you I will start again from the beginning.

If you don't want to start again (and I can understand you, I went crazy for days before having some results...) you have this opportunities:

1 - If you want just to make a transaction because ethereum are falling in price now and you are in panic you can use light sync for syncing, make your transaction and, when you stop praying and shout in your room for a price peak, try with calm to sync your blockchain with fast sync again.
2 - wait two days more with your current situation and see if something changes.

About point number 1, I think light sync is not an experimental feature any more (but maybe someone else can confirm)... and I succeed to make a transaction with a light sync blockchain without problems.
If you want to start again with point number 2 later, you can close geth (because your situation is already corrupted) and rename your blockchiain directory .ethereum/geth. If you are ok instead for clear your current blockchain just use geth removedb on the operating system shell.
After that, for starting light sync (different from fast sync!), I have started geth with the command:
geth --light --cache=1024
and wait just 2 or 3 hour for download a 600Mb light blockchain. After that you can make your transaction. Again this is just my experience for helping people, no responsabilities if you lose your ethereum.
Hope it helps
Marco

@skarn01

This comment has been minimized.

skarn01 commented Sep 15, 2017

hi @brennino, you're right that strange that my starting block is not 0 as i haven't stop the geth daemon...

what i want to do is develop my own services using the chain ( got experience creating an ICO for my boss, now i got some interest in that technology ^^ ) so i don't worry for money i currently put here, there's currently none, ahah.

i'll try the --light option after the geth removedb. --light still give me possibility to work with the chain and see full block after the first sync?

Thank you and I'll come back with update on my situation.

@TooBug

This comment has been minimized.

TooBug commented Jun 17, 2018

@Othman21 Oth

Yes, When it's finished, eth.syncing returns false.

The number is given above. KnownStates is quite similar to pulledStates.

@Othman21

This comment has been minimized.

Othman21 commented Jun 17, 2018

@TooBug Can you tell me the exact processed number that you see right now ?
for exemple i'm at processed=193996209

@jdowning100

This comment has been minimized.

jdowning100 commented Jun 17, 2018

FWIW I was able to get geth to fully sync by waiting until eth.blockNumber is near the numbers in eth.syncing and then restarting geth. I was able to do this at ~160m states. After restarting geth, it took about 20 min to catch up to the blockchain and now eth.syncing is false and the only output now is 'imported new chain segment' every time a new block is found.

@tinschel

This comment has been minimized.

tinschel commented Jun 18, 2018

here is an output of mine taken on 16JUN2018 at 6:18am PTD:

>eth.syncing { currentBlock: 5799102, highestBlock: 5799188, knownStates: 96279752, pulledStates: 96279752, startingBlock: 5799001 }

@Othman21

This comment has been minimized.

Othman21 commented Jun 19, 2018

@tinschel here is an output of mine taken on 19JUN2018 at 7:32am PTD:
> eth.syncing { currentBlock: 5815191, highestBlock: 5815294, knownStates: 198143487, pulledStates: 198143486, startingBlock: 5815181 }

@codepushr

This comment has been minimized.

codepushr commented Jun 21, 2018

Just to clarify... fastsync is now default... and I may quit and restart geth with fast enabled?

Anyway I'm currently at:

> eth.syncing
{
  currentBlock: 5827681,
  highestBlock: 5827747,
  knownStates: 96988858,
  pulledStates: 96988508,
  startingBlock: 5824114
}
> eth.blockNumber
0

@tinschel @Othman21 How is this possible? 100% more state entries in 3 days?

@codepushr

This comment has been minimized.

codepushr commented Jun 21, 2018

@Othman21 This is nuts! 29 days and 200m state entries? Crazy...

@Othman21

This comment has been minimized.

Othman21 commented Jun 21, 2018

@codepushr yes you can, i run this command :
./geth --cache=25000 --rpc --maxpeers 25 --fast

I have not finished syncing yet, today it will be 29 days

eth.syncing

{
currentBlock: 5829510,
highestBlock: 5829582,
knownStates: 203714648,
pulledStates: 203714648,
startingBlock: 5829510
}

eth.blockNumber
0

@Othman21

This comment has been minimized.

Othman21 commented Jun 21, 2018

@codepushr i know
I'm looking for someone who has finished syncing to tell me the current knownStates that he has to get an idea if I'm far or near.

@codepushr

This comment has been minimized.

codepushr commented Jun 21, 2018

It's so bad that there is no mechanism to determine the absolute progress...

@tinschel

This comment has been minimized.

tinschel commented Jun 22, 2018

@codepushr : yes, fast sync is enabled by default so you don't have to specify it on command line, BUT once you start sync'ing and you restart geth, it will automatically DISABLE fast sync; so best not to restart

@codepushr

This comment has been minimized.

codepushr commented Jun 23, 2018

@tinschel Really? So even when restarting with --fast or --syncmode=fast it will boot up in full sync and I would need to remove the db and restart from scratch to get a fast sync?

@wtfiwtz

This comment has been minimized.

wtfiwtz commented Jun 23, 2018

I'm fairly certain that it is not the case... you are in fast sync until you hit the pivot point. Then eth.blockNumber will be a positive value (not zero). From that point onwards, you are in full sync mode.

@wtfiwtz

This comment has been minimized.

wtfiwtz commented Jun 23, 2018

Here are the details of the pivot implementation: #14460 and 0042f13

@tinschel

This comment has been minimized.

tinschel commented Jun 23, 2018

I would just not bother specifying --fast on command line or removing your DB and restarting in the hope that it will be faster. just run geth without the option and keep going! If you have to restart geth don't specify the option. geth will use fast by default if it can. otherwise it will give you a message that fast is disabled.

@Othman21

This comment has been minimized.

Othman21 commented Jun 25, 2018

@codepushr @tinschel any news ?

eth.blockNumber
0
eth.syncing
{
currentBlock: 5852375,
highestBlock: 5852457,
knownStates: 213724149,
pulledStates: 213706822,
startingBlock: 5852248
}

@codepushr

This comment has been minimized.

codepushr commented Jun 25, 2018

@Othman21 Currently at 121m states... I'll need another week to catch up lol.

@tinschel

This comment has been minimized.

tinschel commented Jun 25, 2018

you unfortunately don't see the known states anymore once synchronization is complete. But my currentBlock is at 5853416 as of 25JUN2018 1218 Pacific Time.

@Othman21

This comment has been minimized.

Othman21 commented Jun 27, 2018

is there anyone who has finished syncing to tell us the current knowstates he has?

eth.syncing
{
currentBlock: 5865970,
highestBlock: 5866080,
knownStates: 218653449,
pulledStates: 218633252,
startingBlock: 5865761
}
eth.blockNumber
0

@tinschel

This comment has been minimized.

tinschel commented Jun 28, 2018

here is where I'm currently at after a 1 hour break:
> eth.syncing { currentBlock: 5866670, highestBlock: 5866837, knownStates: 96279752, pulledStates: 96279752, startingBlock: 5866459 }

@codepushr

This comment has been minimized.

codepushr commented Jun 28, 2018

@tinschel are you already synced and just paused it for an hour to demonstrate? if so, how come your states are less than 1/2 of @Othman21 's?

@FreekPaans

This comment has been minimized.

FreekPaans commented Jun 28, 2018

I don't think pulledStates can be used for progress indication, since I just reconnected a node after a while and that one didn't get beyond 115m states.

@tinschel

This comment has been minimized.

tinschel commented Jun 28, 2018

@codepushr yes I'm sync'ed and just paused for an hour. that's when I sent the latest eth.syncing. the states are a mystery to me. like @FreekPaans said, they are not a good indicator for sync completion.

@Othman21

This comment has been minimized.

Othman21 commented Jun 29, 2018

@FreekPaans did you finish the sync ?
I have not finished syncing yet, today it will be 37 days.

eth.syncing
{
  currentBlock: 5876059,
  highestBlock: 5876129,
  knownStates: 223140030,
  pulledStates: 223136789,
  startingBlock: 5875977
}
eth.blockNumber
0
df
Filesystem     1K-blocks      Used Available Use% Mounted on
/dev/simfs     524288000 126645968 397642032  25% /

@codepushr run it in background
sudo nano /etc/systemd/system/eth.service

[Unit]
Description=eth for Pool
After=network-online.target

[Service]
ExecStart=/home/eth-geth/build/bin/geth --cache=25000 --rpc  --maxpeers 25 --fast
Restart=always
RestartSec=3
User=root

[Install]
WantedBy=multi-user.target

sudo systemctl enable eth
sudo systemctl start eth
sudo systemctl status eth

@FreekPaans

This comment has been minimized.

FreekPaans commented Jun 29, 2018

@Othman21

This comment has been minimized.

Othman21 commented Jun 30, 2018

@FreekPaans
Yes I saw them, the geth gets only the last block and sometimes some Knowstates and it's very "slow"
I just changed my command line like yours
geth --maxpeers 25 --cache 25000 --verbosity 4 --syncmode full
Can you please do a screenshot on the lines that appears in your terminal to get an idea
You have a vps more powerful than mine (x3) lol

@FreekPaans

This comment has been minimized.

FreekPaans commented Jul 2, 2018

@Othman21 see attached. This is when I restart a node that was last fully synced a couple of hours ago.
geth-detail.log

@dreamingodd

This comment has been minimized.

dreamingodd commented Sep 19, 2018

I have 2 servers to sync. A for a week, B for 2 weeks. Here are their states:
Machine A:

> eth.syncing
{
  currentBlock: 6358077,
  highestBlock: 6358143,
  knownStates: 167673098,
  pulledStates: 167673097,
  startingBlock: 6357998
}
> eth.blockNumber
0
> net.peerCount
21

Machine B:

> eth.syncing
{
  currentBlock: 6358040,
  highestBlock: 6358157,
  knownStates: 208173888,
  pulledStates: 208173888,
  startingBlock: 6358040
}
> eth.blockNumber
0
> net.peerCount
2

I succeeded before, the "state entries" log ends at 150 millions I recall.
Now state entries more than 160 millions and 200 millions. I wonder when it will ends...

@kaythxbye

This comment has been minimized.

kaythxbye commented Sep 28, 2018

@dreamingodd Do you have any updates (e.g. at which number the states were finishing)?

@tinschel

This comment has been minimized.

tinschel commented Sep 28, 2018

@dreamingodd , I've been sync'ed for several months now; when I restart geth, it has to re-sync just the last few blocks. Here is what I get when I do that today (9/28/2018 at 11:41am PT):
> eth.syncing { currentBlock: 6416641, highestBlock: 6416662, knownStates: 96279752, pulledStates: 96279752, startingBlock: 6416641 }

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment