Willian Mitsuda

`--sync.block.loop.limit=4096` does not work well with 64GB machine, OOO ``` [1322923.224586] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/[email protected]/app.slice/erigon.service,task=erigon,pid=348048,uid=1000 [1322923.225486] Out of memory: Killed process 348048 (erigon) total-vm:4428816168kB, anon-rss:56179076kB, file-rss:7892kB, shmem-rss:0kB, UID:1000 pgtables:1402632kB oom_score_adj:200 [1322926.093216] oom_reaper: reaped...

more about previous OOO:

at block ~23.73M now (end of 11/2025), it passed the first bloat, there is a second bloat post-devconnect. so far my conclusions: - step size reduction didn't matter afterall. the...

> [@wmitsuda](https://github.com/wmitsuda) you've misunderstood the reason behind reducing `--sync.loop.block.limit`. It was not to increase sync speed (nobody said that). It was to gather more fine granularity of metrics about table...

for the record, the bootnode ethpandaops is running is showing similar behavior, also 64GB mem machine, stuck around same block, OOM forever. I recommended `--sync.loop.block.limit=1024` to constrain mem usage.

> 2. If you see duplicate values ​​in the history, it might be a history bug (or you're reading it incorrectly; show what methods/code you're using). Look at the HistoryRange...

I was actually thinking about embedding this info in the Sourcify logo itself, maybe adding a small overlay to the Sourcify logo, in order to save horizontal space.

I asked AI to simulate it, WDYT? I think we don't need to modify the Sourcify logo, but should be possible to use styling to create the effect.

still a little big, could you shrink the checkmark to be ~1/3 of the sourcify logo dimensions? that's approximately the size in the AI-generated simulation above, and it looks a...

> The contract verification status is now also shown in the tab: > it looks like it broke the vertical alignment