Skip to content
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

Syncing 3 days behind every time #439

Closed
urkishan opened this issue Oct 5, 2021 · 40 comments
Closed

Syncing 3 days behind every time #439

urkishan opened this issue Oct 5, 2021 · 40 comments
Labels
question Further information is requested

Comments

@urkishan
Copy link

urkishan commented Oct 5, 2021

System information

AWS Instance

Instance type : c5.4xlarge
Ram Size : 32 GB
CPU : 16

Disk Configurations :

Disk type : GP3
Disk Size : 4000 GiB
IOPS : 16000
Throughput : 500 MB/s

Geth version:

Geth
Version: 1.1.2
Git Commit: c4f931212903b3ee8495c36ac374340aec4ac269
Git Commit Date: 20210825
Architecture: amd64
Go Version: go1.15.14
Operating System: linux
GOPATH=/home/ubuntu/go
GOROOT=/usr/local/go

The blockchain was synced before but when I restarted It is now 3 days behind. I don't know what is wrong with the BSC network. My entire system is suffering because of this. Kindly anyone help me to resolve this.

I've done everything as you can see the configurations. It seems I am installing a project of NASA.

Here is the out for eth.syncing

instance: Geth/v1.1.2-c4f93121-20210825/linux-amd64/go1.15.14
coinbase: 0xff82b410814736762246d9382aeccc13cacb85ce
at block: 11428396 (Sat Oct 02 2021 18:04:03 GMT+0000 (UTC))
 datadir: /home/ubuntu/node

> eth.syncing
{
  currentBlock: 11428399,
  highestBlock: 11475954,
  knownStates: 297473485,
  pulledStates: 297473485,
  startingBlock: 11392128
}
> 
@0fuz
Copy link

0fuz commented Oct 5, 2021

Hello, what about your config.toml and start geth command arguments?

if target make full sync then GP3 more than needed, basic GP2 enough for me and costs 2x less.

@DryDragon10
Copy link

Hello, what about your config.toml and start geth command arguments?

if target make full sync then GP3 more than needed, basic GP2 enough for me and costs 2x less.

Could you share your config.toml file and the command pls? I'm having the same issue. Synced few days ago but now always 100ish blocks behind

@urkishan
Copy link
Author

urkishan commented Oct 6, 2021

Here is my config.toml file @0fuz :

[Eth]
NetworkId = 56
NoPruning = false
NoPrefetch = false
LightPeers = 100
UltraLightFraction = 75
TrieTimeout = 100000000000
EnablePreimageRecording = false
EWASMInterpreter = ""
EVMInterpreter = ""

[Eth.Miner]
GasFloor = 30000000
GasCeil = 40000000
GasPrice = 1000000000
Recommit = 10000000000
Noverify = false

[Eth.TxPool]
Locals = []
NoLocals = true
Journal = "transactions.rlp"
Rejournal = 3600000000000
PriceLimit = 1000000000
PriceBump = 10
AccountSlots = 512
GlobalSlots = 10000
AccountQueue = 256
GlobalQueue = 5000
Lifetime = 10800000000000

[Eth.GPO]
Blocks = 20
Percentile = 60
OracleThreshold = 20

[Node]
IPCPath = "geth.ipc"
HTTPHost = "0.0.0.0"
NoUSB = true
InsecureUnlockAllowed = false
HTTPPort = 8545
HTTPVirtualHosts = ["*"]
HTTPModules = ["eth", "net", "web3", "txpool", "parlia", "personal"]
WSPort = 8546
WSModules = ["net", "web3", "eth", "personal"]

[Node.P2P]
MaxPeers = 30
NoDiscovery = false
BootstrapNodes = ["enode://1cc4534b14cfe351ab740a1418ab944a234ca2f702915eadb7e558a02010cb7c5a8c295a3b56bcefa7701c07752acd5539cb13df2aab8ae2d98934d712611443@52.71.43.172:30311","enode://28b1d16562dac280dacaaf45d54516b85bc6c994252a9825c5cc4e080d3e53446d05f63ba495ea7d44d6c316b54cd92b245c5c328c37da24605c4a93a0d099c4@34.246.65.14:30311","enode://5a7b996048d1b0a07683a949662c87c09b55247ce774aeee10bb886892e586e3c604564393292e38ef43c023ee9981e1f8b335766ec4f0f256e57f8640b079d5@35.73.137.11:30311"]
StaticNodes = ["enode://f3cfd69f2808ef64838abd8786342c0b22fdd28268703c8d6812e26e109f9a7cb2b37bd49724ebb46c233289f22da82991c87345eb9a2dadeddb8f37eeb259ac@18.180.28.21:30311","enode://ae74385270d4afeb953561603fcedc4a0e755a241ffdea31c3f751dc8be5bf29c03bf46e3051d1c8d997c45479a92632020c9a84b96dcb63b2259ec09b4fde38@54.178.30.104:30311","enode://d1cabe083d5fc1da9b510889188f06dab891935294e4569df759fc2c4d684b3b4982051b84a9a078512202ad947f9240adc5b6abea5320fb9a736d2f6751c52e@54.238.28.14:30311","enode://f420209bac5324326c116d38d83edfa2256c4101a27cd3e7f9b8287dc8526900f4137e915df6806986b28bc79b1e66679b544a1c515a95ede86f4d809bd65dab@54.178.62.117:30311","enode://c0e8d1abd27c3c13ca879e16f34c12ffee936a7e5d7b7fb6f1af5cc75c6fad704e5667c7bbf7826fcb200d22b9bf86395271b0f76c21e63ad9a388ed548d4c90@54.65.247.12:30311","enode://f1b49b1cf536e36f9a56730f7a0ece899e5efb344eec2fdca3a335465bc4f619b98121f4a5032a1218fa8b69a5488d1ec48afe2abda073280beec296b104db31@13.114.199.41:30311","enode://4924583cfb262b6e333969c86eab8da009b3f7d165cc9ad326914f576c575741e71dc6e64a830e833c25e8c45b906364e58e70cdf043651fd583082ea7db5e3b@18.180.17.171:30311","enode://4d041250eb4f05ab55af184a01aed1a71d241a94a03a5b86f4e32659e1ab1e144be919890682d4afb5e7afd837146ce584d61a38837553d95a7de1f28ea4513a@54.178.99.222:30311","enode://b5772a14fdaeebf4c1924e73c923bdf11c35240a6da7b9e5ec0e6cbb95e78327690b90e8ab0ea5270debc8834454b98eca34cc2a19817f5972498648a6959a3a@54.170.158.102:30311","enode://f329176b187cec87b327f82e78b6ece3102a0f7c89b92a5312e1674062c6e89f785f55fb1b167e369d71c66b0548994c6035c6d85849eccb434d4d9e0c489cdd@34.253.94.130:30311","enode://cbfd1219940d4e312ad94108e7fa3bc34c4c22081d6f334a2e7b36bb28928b56879924cf0353ad85fa5b2f3d5033bbe8ad5371feae9c2088214184be301ed658@54.75.11.3:30311","enode://c64b0a0c619c03c220ea0d7cac754931f967665f9e148b92d2e46761ad9180f5eb5aaef48dfc230d8db8f8c16d2265a3d5407b06bedcd5f0f5a22c2f51c2e69f@54.216.208.163:30311","enode://352a361a9240d4d23bb6fab19cc6dc5a5fc6921abf19de65afe13f1802780aecd67c8c09d8c89043ff86947f171d98ab06906ef616d58e718067e02abea0dda9@79.125.105.65:30311","enode://bb683ef5d03db7d945d6f84b88e5b98920b70aecc22abed8c00d6db621f784e4280e5813d12694c7a091543064456ad9789980766f3f1feb38906cf7255c33d6@54.195.127.237:30311","enode://11dc6fea50630b68a9289055d6b0fb0e22fb5048a3f4e4efd741a7ab09dd79e78d383efc052089e516f0a0f3eacdd5d3ffbe5279b36ecc42ad7cd1f2767fdbdb@46.137.182.25:30311","enode://21530e423b42aed17d7eef67882ebb23357db4f8b10c94d4c71191f52955d97dc13eec03cfeff0fe3a1c89c955e81a6970c09689d21ecbec2142b26b7e759c45@54.216.119.18:30311","enode://d61a31410c365e7fcd50e24d56a77d2d9741d4a57b295cc5070189ad90d0ec749d113b4b0432c6d795eb36597efce88d12ca45e645ec51b3a2144e1c1c41b66a@34.204.129.242:30311","enode://bb91215b1d77c892897048dd58f709f02aacb5355aa8f50f00b67c879c3dffd7eef5b5a152ac46cdfb255295bec4d06701a8032456703c6b604a4686d388ea8f@75.101.197.198:30311","enode://786acbdf5a3cf91b99047a0fd8305e11e54d96ea3a72b1527050d3d6f8c9fc0278ff9ef56f3e56b3b70a283d97c309065506ea2fc3eb9b62477fd014a3ec1a96@107.23.90.162:30311","enode://4653bc7c235c3480968e5e81d91123bc67626f35c207ae4acab89347db675a627784c5982431300c02f547a7d33558718f7795e848d547a327abb111eac73636@54.144.170.236:30311","enode://c6ffd994c4ef130f90f8ee2fc08c1b0f02a6e9b12152092bf5a03dd7af9fd33597d4b2e2000a271cc0648d5e55242aeadd6d5061bb2e596372655ba0722cc704@54.147.151.108:30311","enode://99b07e9dc5f204263b87243146743399b2bd60c98f68d1239a3461d09087e6c417e40f1106fa606ccf54159feabdddb4e7f367559b349a6511e66e525de4906e@54.81.225.170:30311","enode://1479af5ea7bda822e8747d0b967309bced22cad5083b93bc6f4e1d7da7be067cd8495dc4c5a71579f2da8d9068f0c43ad6933d2b335a545b4ae49a846122b261@52.7.247.132:30311","enode://43562d35f274d9e93f5ccac484c7cb185eabc746dbc9f3a56c36dc5a9ef05a3282695de7694a71c0bf4600651f49395b2ee7a6aaef857db2ac896e0fcbe6b518@35.73.15.198:30311","enode://08867e57849456fc9b0b00771f53e87ca6f2dd618c23b34a35d0c851cd484a4b7137905c5b357795025b368e4f8fe4c841b752b0c28cc2dbbf41a03d048e0e24@35.74.39.234:30311"]
ListenAddr = ":30311"
EnableMsgEvents = false

[Node.HTTPTimeouts]
ReadTimeout = 30000000000
WriteTimeout = 30000000000
IdleTimeout = 120000000000

[Node.LogConfig]
FilePath = "bsc.log"
MaxBytesSize = 10485760
Level = "info"
FileRoot = ""

And the command I am using to run the node:

./geth --config ./config.toml --datadir ./node --cache 18000 --rpc.allow-unprotected-txs --txlookuplimit 0 --snapshot=false

And this is the current log:

t=2021-10-06T06:34:19+0000 lvl=info msg="Imported new chain segment"            blocks=3  txs=406  mgas=69.649  elapsed=8.522s    mgasps=8.172  number=11,461,598 hash=0x289342c801c52b81efd6fac3cfe584eb67d64392ded00f06bd9adcea36d401a3 age=2d8h38m  dirty="385.56 MiB"
t=2021-10-06T06:34:29+0000 lvl=info msg="Imported new chain segment"            blocks=6  txs=833  mgas=128.231 elapsed=10.257s   mgasps=12.501 number=11,461,604 hash=0x30f97e4433abd6029be364da223965ccaf347ebe5b5bc85deb1ceda6ca3c4deb age=2d8h38m  dirty="389.53 MiB"
t=2021-10-06T06:34:38+0000 lvl=info msg="Imported new chain segment"            blocks=4  txs=633  mgas=116.583 elapsed=8.806s    mgasps=13.239 number=11,461,608 hash=0xd07997047bf89e192796405a7dacb77f7c6e23b80d929c1c30bbb111dfe2bb52 age=2d8h38m  dirty="394.02 MiB"
t=2021-10-06T06:34:41+0000 lvl=info msg="Persisted trie from memory database"   nodes=182,202 size="56.16 MiB" time=1.741431449s gcnodes=168,441 gcsize="65.87 MiB"  gctime=638.183521ms livenodes=718,372   livesize="-33934228.00 B"
t=2021-10-06T06:34:46+0000 lvl=info msg="Imported new chain segment"            blocks=4  txs=552  mgas=79.133  elapsed=8.416s    mgasps=9.402  number=11,461,612 hash=0xe972dcda40a017d8b2cb9ecd6d4bde37898237b3f40f72fa86b3091b678dcfb9 age=2d8h38m  dirty="328.04 MiB"
t=2021-10-06T06:34:56+0000 lvl=info msg="Imported new chain segment"            blocks=7  txs=977  mgas=141.427 elapsed=9.679s    mgasps=14.611 number=11,461,619 hash=0x85b5ed10995af49666db142032ee3e76c7b800a34c6017093924035868f47eeb age=2d8h38m  dirty="338.91 MiB"
t=2021-10-06T06:35:05+0000 lvl=info msg="Imported new chain segment"            blocks=6  txs=934  mgas=140.920 elapsed=9.065s    mgasps=15.545 number=11,461,625 hash=0x5078a8c47371256acd6a893cb589df64ba63e5b1f802299539d9a3e0d9889f99 age=2d8h38m  dirty="347.36 MiB"
t=2021-10-06T06:35:08+0000 lvl=info msg="Deep froze chain segment"              blocks=34 elapsed=41.056ms  number=11,371,627 hash=0xe8a6111c1810a5d37f9af935f0c394600eddade327542fe3cabc15b35d17f9d7
t=2021-10-06T06:35:14+0000 lvl=info msg="Imported new chain segment"            blocks=5  txs=873  mgas=120.796 elapsed=8.848s    mgasps=13.651 number=11,461,630 hash=0x317ff59c35ac40f4d2a8650e12931fa468cda8dc976f541b6a5b928065ff54c9 age=2d8h38m  dirty="354.82 MiB"
t=2021-10-06T06:35:38+0000 lvl=info msg="Imported new chain segment"            blocks=5  txs=745  mgas=113.457 elapsed=24.609s   mgasps=4.610  number=11,461,635 hash=0x475f62716f4006fdbf7ecd1fa2904f691b99f37a936517acf067a131a1d8dd70 age=2d8h38m  dirty="359.51 MiB"

@benharbit
Copy link

did you try snap syncmode when starting geth with "--syncmode snap"?

@urkishan
Copy link
Author

urkishan commented Oct 7, 2021

No I haven't tried with --syncmode snap does this help @risingsun007?

@benharbit
Copy link

No I haven't tried with --syncmode snap does this help @risingsun007?

Using snap syncmode was the only way I was able to successfully sync my node.

@DryDragon10
Copy link

finally synced after so many days...

@benharbit
Copy link

finally synced after so many days...

What syncmode did you use to sync?

@DryDragon10
Copy link

finally synced after so many days...

What syncmode did you use to sync?

default

@0fuz
Copy link

0fuz commented Oct 7, 2021

@urkishan
Sorry for the delay, I don't get notice(

config.toml part:

DataDir = "node"
InsecureUnlockAllowed = false
NoUSB = true
IPCPath = "geth.ipc"
HTTPHost = "127.0.0.1"
HTTPPort = 8575
HTTPVirtualHosts = ["localhost"]
HTTPModules = ["eth", "net", "web3", "txpool"]
WSPort = 8546
WSModules = ["net", "web3", "eth", "txpool"]

[Node.P2P]
MaxPeers = 90 # seems important, 90 there ll be admin.peers=30

For 32gb RAM i'm using
./geth --config ./config.toml --datadir ./node --cache 25000 --ws

1d ago this setup gave me average 2-3 block sync in a second

@urkishan
Copy link
Author

urkishan commented Oct 7, 2021

So @0fuz should I increase my MaxPeers to 90 and change the cache to 25K?

@0fuz
Copy link

0fuz commented Oct 7, 2021

yes, hope it can help, geth depends of RAM a lot

@urkishan
Copy link
Author

urkishan commented Oct 7, 2021

This is the current ram uses. I've increased the cache and MaxPeers

Screenshot from 2021-10-07 18-11-57

@urkishan
Copy link
Author

urkishan commented Oct 7, 2021

I don't understand why they are not solving this issue, As this is not my first issue in here I've raised related to the syncing problem. They should really provide a full documentation how to sync or let us know that they are having some problem.

Here is my other issue I've raised for them but I didn't get any help from this team #258

@urkishan
Copy link
Author

urkishan commented Oct 7, 2021

And here we have something else I don't know if it is a normal behaviour or something else:

> 
> eth.syncing
{
  currentBlock: 11509238,
  highestBlock: 11565522,
  knownStates: 297473485,
  pulledStates: 297473485,
  startingBlock: 11509021
}
> eth.syncing
{
  currentBlock: 11509239,
  highestBlock: 11565522,
  knownStates: 297473485,
  pulledStates: 297473485,
  startingBlock: 11509021
}
> eth.syncing
{
  currentBlock: 11509240,
  highestBlock: 11565522,
  knownStates: 297473485,
  pulledStates: 297473485,
  startingBlock: 11509021
}

The highestBlock is not moving from last 1 hours :( It seems I'm syncing the BSC from the Moon :(

@0fuz
Copy link

0fuz commented Oct 7, 2021

when your currentBlock so far from highestBlock, highestBlock might not be real latest network known.

@0fuz
Copy link

0fuz commented Oct 7, 2021

I had 100 blocks behind too, and solved it by making full sync from bsc-snapshots

@DryDragon10
Copy link

And here we have something else I don't know if it is a normal behaviour or something else:

> 
> eth.syncing
{
  currentBlock: 11509238,
  highestBlock: 11565522,
  knownStates: 297473485,
  pulledStates: 297473485,
  startingBlock: 11509021
}
> eth.syncing
{
  currentBlock: 11509239,
  highestBlock: 11565522,
  knownStates: 297473485,
  pulledStates: 297473485,
  startingBlock: 11509021
}
> eth.syncing
{
  currentBlock: 11509240,
  highestBlock: 11565522,
  knownStates: 297473485,
  pulledStates: 297473485,
  startingBlock: 11509021
}

The highestBlock is not moving from last 1 hours :( It seems I'm syncing the BSC from the Moon :(

Looks like you're syncing 1 block a second? You may still catch up but it will take ages...
I don't think your disk is a NVMe disk. SSD just can't cope anymore

@DryDragon10
Copy link

BTW, I used 1000 peers in my conf file

@urkishan
Copy link
Author

My node is still 3 days behind. I don't know what is going on. Can somebody let me know what should I do?

@urkishan
Copy link
Author

@DryDragon10 your node is synced?

@DryDragon10
Copy link

Yes mine has been synced fine for a week

@DryDragon10
Copy link

My node is still 3 days behind. I don't know what is going on. Can somebody let me know what should I do?

can you post your status here?

@bpbogdanpop
Copy link

Guys, this is still unclear. What should I do to sync a full-node? I've been trying for a week now...
Tell me what kind of instance is needed on AWS. Does it work only with snapshot syncmode?

@bpbogdanpop
Copy link

@DryDragon10 @risingsun007

@0fuz
Copy link

0fuz commented Oct 18, 2021

And here we have something else I don't know if it is a normal behaviour or something else:

> 
> eth.syncing
{
  currentBlock: 11509238,
  highestBlock: 11565522,
  knownStates: 297473485,
  pulledStates: 297473485,
  startingBlock: 11509021
}
> eth.syncing
{
  currentBlock: 11509239,
  highestBlock: 11565522,
  knownStates: 297473485,
  pulledStates: 297473485,
  startingBlock: 11509021
}
> eth.syncing
{
  currentBlock: 11509240,
  highestBlock: 11565522,
  knownStates: 297473485,
  pulledStates: 297473485,
  startingBlock: 11509021
}

The highestBlock is not moving from last 1 hours :( It seems I'm syncing the BSC from the Moon :(

I saw similar change of 'currentBlock' after I made aws.volume.snapshot and unzipped it, I solved it by downloading latest snapshot(

@urkishan
Copy link
Author

My node is still 3 days behind. I don't know what is going on. Can somebody let me know what should I do?

can you post your status here?

eth.syncing
{
currentBlock: 11861303,
highestBlock: 11932837,
knownStates: 297473485,
pulledStates: 297473485,
startingBlock: 11861295
}

@urkishan
Copy link
Author

I am still not able to solve this issue, it seems I've to reinstall the BSC chain.

@DryDragon10
Copy link

My node is still 3 days behind. I don't know what is going on. Can somebody let me know what should I do?

can you post your status here?

eth.syncing
{
currentBlock: 11861303,
highestBlock: 11932837,
knownStates: 297473485,
pulledStates: 297473485,
startingBlock: 11861295
}

This is just way too slow. It seems that your vps doesn't meet the requirements of a full node

@jhaigcg
Copy link

jhaigcg commented Oct 25, 2021

My node is still 3 days behind. I don't know what is going on. Can somebody let me know what should I do?

can you post your status here?

eth.syncing
{
currentBlock: 11861303,
highestBlock: 11932837,
knownStates: 297473485,
pulledStates: 297473485,
startingBlock: 11861295
}

This is just way too slow. It seems that your vps doesn't meet the requirements of a full node

Hi DryDragon10, did you have your node successfully synced from scratch or a snapshot copy from https://github.com/binance-chain/bsc-snapshots?

@urkishan
Copy link
Author

I've started 3 node for syncing from more than 1 week but it still nothing. I think it's time to move to other blockchain because they aren't supporting and telling us anything that what is going on.

@0fuz
Copy link

0fuz commented Nov 1, 2021

@de-ltd
Copy link

de-ltd commented Nov 15, 2021

tl:dr; but if you are experiencing huge block loss after restarting geth, you should maybe start it as a daemon and configure the timeout to around 5 minutes - this way it has time to persist the data from memory to disk.

@icex
Copy link

icex commented Nov 25, 2021

I could barely sync my server in about 12h after 2 weeks of trying different stuff. I previously had a regular SATA SSD(Intel DC enterprise part), then upgraded to a Samsung NVME but using a ZFS format == fail. Then I formatted it to XFS(a lot of people suggested this for geth/leveldb performance) and like magic it worked in under 12h. The point is IO performance is critical

Now the only issue is that sometimes it laggs 1-2 blocks, but I guess the network is really congested(a lot of official nodes are out of sync by upto 40 blocks sometimes), see https://bscscan.com/chart/tx

I wrote a quick script to check some public nodes(it just queries current block):

[latency test] 357ms for https://bsc-dataseed1.ninicoin.io/ is 6 blocks behind!!!
[latency test] 391.5ms for https://bsc-dataseed4.defibit.io/ is 6 blocks behind!!!
[latency test] 412.5ms for https://bsc-dataseed2.binance.org/ is 6 blocks behind!!!
[latency test] 451.5ms for https://bsc-dataseed4.ninicoin.io/ is 4 blocks behind!!!
[latency test] 662.5ms for https://bsc-dataseed1.defibit.io/ is 8 blocks behind!!!
[latency test] 678ms for https://bsc-dataseed3.defibit.io/ is 8 blocks behind!!!
[latency test] 703.5ms for https://bsc-dataseed2.ninicoin.io/ is 8 blocks behind!!!
[latency test] 729ms for https://bsc-dataseed2.defibit.io/ is 8 blocks behind!!!
[latency test] 732.5ms for https://bsc-dataseed3.ninicoin.io/ is 8 blocks behind!!!
[latency test] 747.5ms for https://bsc-dataseed4.binance.org/ is 8 blocks behind!!!

@DryDragon10
Copy link

I could barely sync my server in about 12h after 2 weeks of trying different stuff. I previously had a regular SATA SSD(Intel DC enterprise part), then upgraded to a Samsung NVME but using a ZFS format == fail. Then I formatted it to XFS(a lot of people suggested this for geth/leveldb performance) and like magic it worked in under 12h. The point is IO performance is critical

Now the only issue is that sometimes it laggs 1-2 blocks, but I guess the network is really congested(a lot of official nodes are out of sync by upto 40 blocks sometimes), see https://bscscan.com/chart/tx

I wrote a quick script to check some public nodes(it just queries current block):

[latency test] 357ms for https://bsc-dataseed1.ninicoin.io/ is 6 blocks behind!!! [latency test] 391.5ms for https://bsc-dataseed4.defibit.io/ is 6 blocks behind!!! [latency test] 412.5ms for https://bsc-dataseed2.binance.org/ is 6 blocks behind!!! [latency test] 451.5ms for https://bsc-dataseed4.ninicoin.io/ is 4 blocks behind!!! [latency test] 662.5ms for https://bsc-dataseed1.defibit.io/ is 8 blocks behind!!! [latency test] 678ms for https://bsc-dataseed3.defibit.io/ is 8 blocks behind!!! [latency test] 703.5ms for https://bsc-dataseed2.ninicoin.io/ is 8 blocks behind!!! [latency test] 729ms for https://bsc-dataseed2.defibit.io/ is 8 blocks behind!!! [latency test] 732.5ms for https://bsc-dataseed3.ninicoin.io/ is 8 blocks behind!!! [latency test] 747.5ms for https://bsc-dataseed4.binance.org/ is 8 blocks behind!!!

would you mind sharing your query script?

@thehood1
Copy link

thehood1 commented Nov 26, 2021

I could barely sync my server in about 12h after 2 weeks of trying different stuff. I previously had a regular SATA SSD(Intel DC enterprise part), then upgraded to a Samsung NVME but using a ZFS format == fail. Then I formatted it to XFS(a lot of people suggested this for geth/leveldb performance) and like magic it worked in under 12h. The point is IO performance is critical

@icex Not in my case. Ubuntu 20.04 , 8-core Ryzen, 32GB RAM, NVME 180k IOPS. Ubuntu is installed on ext4 partition, bsc data on partition with xfs file system.

Syncing 3 days , still 30k blocks behind latest.

Can you please share your config.toml file and start command?

@icex
Copy link

icex commented Nov 27, 2021

I could barely sync my server in about 12h after 2 weeks of trying different stuff. I previously had a regular SATA SSD(Intel DC enterprise part), then upgraded to a Samsung NVME but using a ZFS format == fail. Then I formatted it to XFS(a lot of people suggested this for geth/leveldb performance) and like magic it worked in under 12h. The point is IO performance is critical

@icex Not in my case. Ubuntu 20.04 , 8-core Ryzen, 32GB RAM, NVME 180k IOPS. Ubuntu is installed on ext4 partition, bsc data on partition with xfs file system.

Syncing 3 days , still 30k blocks behind latest.

Can you please share your config.toml file and start command?

I'm running a Supermicro server with Xeon(R) Silver 4210 CPU @ 2.20GHz (10c/20t cpu), 64GB ram, Samsung 970 EVO Plus 2TB NVME. But it is also running stuff as well.

config.toml

[Eth]
NetworkId = 56
NoPruning = false
NoPrefetch = false
LightPeers = 5
UltraLightFraction = 75
TrieTimeout = 100000000000
EnablePreimageRecording = false
EWASMInterpreter = ""
EVMInterpreter = ""

[Eth.Miner]
GasFloor = 30000000
GasCeil = 40000000
GasPrice = 1000000000
Recommit = 10000000000
Noverify = false

[Eth.TxPool]
Locals = []
NoLocals = true
Journal = "transactions.rlp"
Rejournal = 3600000000000
PriceLimit = 1000000000
PriceBump = 10
AccountSlots = 512
GlobalSlots = 10000
AccountQueue = 256
GlobalQueue = 5000
Lifetime = 10800000000000

[Eth.GPO]
Blocks = 20
Percentile = 60
OracleThreshold = 20

[Node]
IPCPath = "geth.ipc"
HTTPHost = "0.0.0.0"
NoUSB = true
InsecureUnlockAllowed = false
HTTPPort = 18545
HTTPVirtualHosts = ["localhost"]
HTTPModules = ["eth", "net", "web3", "txpool", "parlia"]
WSPort = 18546
WSHost = "0.0.0.0"
WSModules = ["net", "web3", "eth"]

[Node.P2P]
MaxPeers = 100
NoDiscovery = false
BootstrapNodes = ["enode://1cc4534b14cfe351ab740a1418ab944a234ca2f702915eadb7e558a02010cb7c5a8c295a3b56bcefa7701c07752acd5539cb13df2aab8ae2d98934d712611443@52.71.43.172:30311","enode://28b1d16562dac280dacaaf45d54516b85bc6c994252a9825c5cc4e080d3e53446d05f63ba495ea7d44d6c316b54cd92b245c5c328c37da24605c4a93a0d099c4@34.246.65.14:30311","enode://5a7b996048d1b0a07683a949662c87c09b55247ce774aeee10bb886892e586e3c604564393292e38ef43c023ee9981e1f8b335766ec4f0f256e57f8640b079d5@35.73.137.11:30311"]
StaticNodes = ["enode://f3cfd69f2808ef64838abd8786342c0b22fdd28268703c8d6812e26e109f9a7cb2b37bd49724ebb46c233289f22da82991c87345eb9a2dadeddb8f37eeb259ac@18.180.28.21:30311","enode://ae74385270d4afeb953561603fcedc4a0e755a241ffdea31c3f751dc8be5bf29c03bf46e3051d1c8d997c45479a92632020c9a84b96dcb63b2259ec09b4fde38@54.178.30.104:30311","enode://d1cabe083d5fc1da9b510889188f06dab891935294e4569df759fc2c4d684b3b4982051b84a9a078512202ad947f9240adc5b6abea5320fb9a736d2f6751c52e@54.238.28.14:30311","enode://f420209bac5324326c116d38d83edfa2256c4101a27cd3e7f9b8287dc8526900f4137e915df6806986b28bc79b1e66679b544a1c515a95ede86f4d809bd65dab@54.178.62.117:30311","enode://c0e8d1abd27c3c13ca879e16f34c12ffee936a7e5d7b7fb6f1af5cc75c6fad704e5667c7bbf7826fcb200d22b9bf86395271b0f76c21e63ad9a388ed548d4c90@54.65.247.12:30311","enode://f1b49b1cf536e36f9a56730f7a0ece899e5efb344eec2fdca3a335465bc4f619b98121f4a5032a1218fa8b69a5488d1ec48afe2abda073280beec296b104db31@13.114.199.41:30311","enode://4924583cfb262b6e333969c86eab8da009b3f7d165cc9ad326914f576c575741e71dc6e64a830e833c25e8c45b906364e58e70cdf043651fd583082ea7db5e3b@18.180.17.171:30311","enode://4d041250eb4f05ab55af184a01aed1a71d241a94a03a5b86f4e32659e1ab1e144be919890682d4afb5e7afd837146ce584d61a38837553d95a7de1f28ea4513a@54.178.99.222:30311","enode://b5772a14fdaeebf4c1924e73c923bdf11c35240a6da7b9e5ec0e6cbb95e78327690b90e8ab0ea5270debc8834454b98eca34cc2a19817f5972498648a6959a3a@54.170.158.102:30311","enode://f329176b187cec87b327f82e78b6ece3102a0f7c89b92a5312e1674062c6e89f785f55fb1b167e369d71c66b0548994c6035c6d85849eccb434d4d9e0c489cdd@34.253.94.130:30311","enode://cbfd1219940d4e312ad94108e7fa3bc34c4c22081d6f334a2e7b36bb28928b56879924cf0353ad85fa5b2f3d5033bbe8ad5371feae9c2088214184be301ed658@54.75.11.3:30311","enode://c64b0a0c619c03c220ea0d7cac754931f967665f9e148b92d2e46761ad9180f5eb5aaef48dfc230d8db8f8c16d2265a3d5407b06bedcd5f0f5a22c2f51c2e69f@54.216.208.163:30311","enode://352a361a9240d4d23bb6fab19cc6dc5a5fc6921abf19de65afe13f1802780aecd67c8c09d8c89043ff86947f171d98ab06906ef616d58e718067e02abea0dda9@79.125.105.65:30311","enode://bb683ef5d03db7d945d6f84b88e5b98920b70aecc22abed8c00d6db621f784e4280e5813d12694c7a091543064456ad9789980766f3f1feb38906cf7255c33d6@54.195.127.237:30311","enode://11dc6fea50630b68a9289055d6b0fb0e22fb5048a3f4e4efd741a7ab09dd79e78d383efc052089e516f0a0f3eacdd5d3ffbe5279b36ecc42ad7cd1f2767fdbdb@46.137.182.25:30311","enode://21530e423b42aed17d7eef67882ebb23357db4f8b10c94d4c71191f52955d97dc13eec03cfeff0fe3a1c89c955e81a6970c09689d21ecbec2142b26b7e759c45@54.216.119.18:30311","enode://d61a31410c365e7fcd50e24d56a77d2d9741d4a57b295cc5070189ad90d0ec749d113b4b0432c6d795eb36597efce88d12ca45e645ec51b3a2144e1c1c41b66a@34.204.129.242:30311","enode://bb91215b1d77c892897048dd58f709f02aacb5355aa8f50f00b67c879c3dffd7eef5b5a152ac46cdfb255295bec4d06701a8032456703c6b604a4686d388ea8f@75.101.197.198:30311","enode://786acbdf5a3cf91b99047a0fd8305e11e54d96ea3a72b1527050d3d6f8c9fc0278ff9ef56f3e56b3b70a283d97c309065506ea2fc3eb9b62477fd014a3ec1a96@107.23.90.162:30311","enode://4653bc7c235c3480968e5e81d91123bc67626f35c207ae4acab89347db675a627784c5982431300c02f547a7d33558718f7795e848d547a327abb111eac73636@54.144.170.236:30311","enode://c6ffd994c4ef130f90f8ee2fc08c1b0f02a6e9b12152092bf5a03dd7af9fd33597d4b2e2000a271cc0648d5e55242aeadd6d5061bb2e596372655ba0722cc704@54.147.151.108:30311","enode://99b07e9dc5f204263b87243146743399b2bd60c98f68d1239a3461d09087e6c417e40f1106fa606ccf54159feabdddb4e7f367559b349a6511e66e525de4906e@54.81.225.170:30311","enode://1479af5ea7bda822e8747d0b967309bced22cad5083b93bc6f4e1d7da7be067cd8495dc4c5a71579f2da8d9068f0c43ad6933d2b335a545b4ae49a846122b261@52.7.247.132:30311","enode://43562d35f274d9e93f5ccac484c7cb185eabc746dbc9f3a56c36dc5a9ef05a3282695de7694a71c0bf4600651f49395b2ee7a6aaef857db2ac896e0fcbe6b518@35.73.15.198:30311","enode://08867e57849456fc9b0b00771f53e87ca6f2dd618c23b34a35d0c851cd484a4b7137905c5b357795025b368e4f8fe4c841b752b0c28cc2dbbf41a03d048e0e24@35.74.39.234:30311"]
ListenAddr = ":30311"
EnableMsgEvents = false

[Node.HTTPTimeouts]
ReadTimeout = 30000000000
WriteTimeout = 30000000000
IdleTimeout = 120000000000

[Node.LogConfig]
FilePath = "bsc.log"
MaxBytesSize = 10485760
Level = "info"
FileRoot = ""

start command

./geth_linux --snapshot=false --syncmode fast --diffsync --config ./config.toml --datadir ./mainnet --cache 8000 --rpc.allow-unprotected-txs --txlookuplimit 0

@keefel keefel added the question Further information is requested label Dec 2, 2021
@RumeelHussainbnb
Copy link
Contributor

We have responded to the question and will proceed to close the case as we didn't get any additional question after 3days.
Please proceed to join our Discord channel for more discussion at https://discord.com/invite/buildnbuild

@amindotb
Copy link

@urkishan Could you resolve this issue finally?

@echoof
Copy link

echoof commented Oct 11, 2022

+1
image
anyone tried syncmode snap? Success ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

15 participants