ahamlat

Another discord user had the same error with Fast Sync and Bonsai as a database, here're the logs ``` Aug 31 19:54:41 validateur2 besu[3598]: 2022-08-31 19:54:41.386+00:00 | EthScheduler-Workers-0 | INFO...

Top components : ``` num #instances #bytes class name (module) ------------------------------------------------------- 1: 146572886 9400658032 [B ([email protected]) 2: 146445748 4686263936 org.apache.tuweni.bytes.MutableArrayWrappingBytes32 3: 6083127 1300789808 [Lorg.apache.tuweni.bytes.Bytes32; 4: 3041563 389320064 org.hyperledger.besu.ethereum.debug.TraceFrame ```

@macfarla : to reproduce, you have to call trace_replayBlockTransactions on a block that contains one or several huge transactions. @matkt was able to reproduce on Ropsten.

@tdiesler : The first thing we can check is either this is related to on-heap memory consumption or native memory consumption. For both cases have fixes and workarounds for both...

> Now, is it using it or not? You can use this command inside your docker container to be sure that Jemalloc is actually loaded : sudo lsof -n -p...

In this case, you can just let it run and see if Jemalloc helps to reduce memory consumption.

Could you share jcmd command results please ?

From the histogram, we can see that we have a lot of Transaction's objects in memory. We already fixed this issue in Besu 22.7.6 and one other similar issue that...

Do you have metrics to share to see why this is so slow ? (block time import, number of connected peers, GC activity, CPU usage, ...etc. If you don't have...

Here some update from the team. We find a bug in the code where all the calls that come through the engine API port (8551) are sequential. For example, especially...