hey, running xdc (full syncmode, gcmode archive, not mining) on multiple nodes. We're experiencing weird issue with debug_traceBlockByNumber calls.
on 24core AMD (AMD EPYC 7413 24-Core Processor) it takes almost 40secs to get the response, on 12core (Intel(R) Xeon(R) E-2386G CPU @ 3.50GHz) the same query takes 15secs. All the same version, data and configuration, we're using nvme disks.
query:
{
"jsonrpc":"2.0",
"method":"debug_traceBlockByNumber",
"params":["0x41A0126", {"tracer": "callTracer", "timeout":"60s"}],
"id":1
}
24 cores:
time_namelookup: 0.000013s
time_connect: 0.000064s
time_appconnect: 0.000000s
time_pretransfer: 0.000084s
time_redirect: 0.000000s
time_starttransfer: 33.867162s
----------
time_total: 33.867536s
12cores:
time_namelookup: 0.000038s
time_connect: 0.000198s
time_appconnect: 0.000000s
time_pretransfer: 0.000260s
time_redirect: 0.000000s
time_starttransfer: 15.226504s
----------
time_total: 15.226841s
we have issue even with these 15secs, is that a common response time?
Any idea about possible tuning? Saw that cache is disabled, no LRU cache, no new tracers as in geth
thanks
Discussion (6)
May I know which network and RPC are you querying? If you are using your own RPC node, what's your start script and the commit id?
Could you please also open an issue on github.com/XinFinOrg/XDPoSChain? Then we can track your problem more effectively.
posted.
github.com/XinFinOrg/XDPoSChain/is...
btw - would be nice to have one place, as I was told to post to telegram, then here, then to github...
I answered in GitHub: github.com/XinFinOrg/XDPoSChain/is...
GitHub is the preferred website for technical issue.
I understand this issue now. I will report on the progress of this issue on GitHub.