Need a lot more details here: logs, heap profile and so on.
I donât understand your question. Can you rephrase?
We are working on reducing the memory needed to store the map that is causing this issue. Best bet for now is to try smaller mutations rather than change snapshot_after.
@martinmr as you mentioned âChange the value of --snapshot_after to a smaller value so that the map is cleared more oftenâ, i changed that value to 1000, and i expect that after 1000 mutations, the memory usage fall down, but i donât see any evidence of effectiveness of that parameter.
also, smaller mutations is not an option for me, because that will cause more mutations, which will reduce the overall speed of data import.
@mrjn as Martin mentioned âwe have enough info on our sideâ, do you need more details yet? if so, it can take some time for me to learn how to gather heap profile and so on, but i can try it.
@mrjn. I think we have enough details on our side for now. The mutations @mbande is running are pretty simple and I was able to reproduce the same issue. It looks like the mmap-based keyCommit map should help with this. Is someone working on that? Last time I heard @ashishgoswami was working on that. is that right?
@mbande I thought changing the --snapshot_after parameter could help but it looks like it doesnât have much effect. Not sure of a workaround if smaller mutations are not doable. Maybe restarting zero once in a while to reset the memory would help? The change we are working on should help but it requires a code change and a new minor release.
Thatâs right. Heâs working on it.
1 Like