-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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
sql: creating an index, user experienced OOM #36381
Comments
@roncrdb can you attach just the memory profile to this issue? Thanks! |
@jordanlewis are you referring to this? |
Yes, thanks! Pasting the major allocation source along with its call stack for reference. @dt, this seems like the same thing you were looking at earlier, right? |
Looks like the link above to the debug zip isn't working, here's a new link to the zip @jordanlewis |
I've been sitting on a change that I think would fix that specific allocation for a long time now that I just PR'ed in #36394. That said, I didn't pursue merging it sooner since I never actually saw that allocation feature significantly in any profiles, so I'm curious if there's another issue happening here. If indeed all that mem belongs to I'll get #36394 out for review now and see about backporting it, but I still want to dig in a bit more to understand how this happens / confirm that removing the copy really will fix it. |
Here's a stack trace from the unhappy node:
... except there were about 30 recursive calls. |
looks like AddSSTable has some retry logic that should only be applied at the highest level of the recursion |
@vivekmenezes we can/should restructure the helpers here a bit, but with #36394 all the calls should be using the same |
OOM fixed in #36394. |
36765: bulk: change AddSSTTable to not be recursive r=vivekmenezes a=vivekmenezes AddSSTTable was recursive to deal with range splits. Unfortunately the recursive call would create new SSTs without freeing the older ones creating a memory buildup that was quadratic. We've seen memory buildup on the order of GBs due to this recursion. fixes #36769 fixes #36381 Release note: None Co-authored-by: Vivek Menezes <[email protected]>
Describe the problem
User ran into OOM while creating an index, also experiencing some slight load from tests.
Here are the top sources of Memory allocation from the node:
DEBUG ZIP
Expected behavior
Index should complete without OOM
Additional data / screenshots
User has been trying to create an index, and has run into multiple issues, may be related to #34878
Environment:
The text was updated successfully, but these errors were encountered: