Revert "exclude sanctum"

[0xRobin]

Opening revert PR so we keep track and retry this model

[0xRobin]

fyi @senyor-kodi

[senyor-kodi]

hey @0xRobin it's a shame it's causing issues

please let me know if I can do anything and keep me updated 🙏

[senyor-kodi]

The check seems to fail due to the cluster running out of memory. We had the same issue when adding it in the first PR #7188 and Jeff suggested to add a time filter for the past week so that the CI would run. We took it out after the tests passed.

Was the memory issue also happening on Dune's end after merging the PR?

[jeff-dude]

The check seems to fail due to the cluster running out of memory. We had the same issue when adding it in the first PR #7188 and Jeff suggested to add a time filter for the past week so that the CI would run. We took it out after the tests passed.

Was the memory issue also happening on Dune's end after merging the PR?

thank you for the patience. typically in prod, we are able to successfully scale up the clusters for merges to help with large datasets + memory issues. even with scaled up clusters, this one is failing. let me take a few minutes to dig into the code a bit closer to ensure we aren't missing anything obvious that could cause these memory errors. the other DEXs that load into dex_solana.trades don't seem to hit this memory issue, so unless this DEX has that much more volume + rows of data, we may be missing something that causes output to explode in size.

in the meantime, please do let me know if we should expect this DEX to have much more data.

[senyor-kodi]

thank you for the patience. typically in prod, we are able to successfully scale up the clusters for merges to help with large datasets + memory issues. even with scaled up clusters, this one is failing. let me take a few minutes to dig into the code a bit closer to ensure we aren't missing anything obvious that could cause these memory errors. the other DEXs that load into dex_solana.trades don't seem to hit this memory issue, so unless this DEX has that much more volume + rows of data, we may be missing something that causes output to explode in size.

in the meantime, please do let me know if we should expect this DEX to have much more data.

Thanks for the update. It might be that it handles more data than other dexes, yes. One of the tables has well over a million rows and at least a couple others have +500k rows.

Aside from that, the decoded tables don't include all the data necessary and I've had to use the solana.instruction_calls table to fill in the gaps. Maybe more efficient filtering when joining with that table would do the trick.

Let me know what you find when you look into the code and if I can be of any help.

[senyor-kodi]

Hey @jeff-dude have you had the chance to look into this?

Let me know if I can help somehow!

[jeff-dude]

Hey @jeff-dude have you had the chance to look into this?

Let me know if I can help somehow!

thank you for the patience. i can share what process i would take, if you wanted to try and provide info back here to help expedite? sorry, busy trying to get other items moving in spellbook.

i would do something like this:

• compile the model into raw sql
• paste into dune app, comment out all code, uncomment the first phase of the model (i.e. table read with filters)
• see how that source looks in terms of row counts, etc etc
• start uncommenting more code until i notice anything that slows down the query result run time
• do similar approach on another DEX that loads into dex_solana.trades to benchmark, since we know those run pretty efficiently
  • what's different, if so? are we missing a join condition that helps performance (i.e. a block number, date partition, etc)? is there a join that truly isn't unique, i.e. exploding row count to more than expected? are we using dunesql functions that slow down performance, to force the model to output desired data (such as union distinct, distinct in selects, etc etc)

hope this helps, if you have time to assist here 🙏

edit: i would also add filters on timeframe, so the app returns things faster. then can slowly open up that timeframe as needed

[senyor-kodi]

thank you for the patience. i can share what process i would take, if you wanted to try and provide info back here to help expedite? sorry, busy trying to get other items moving in spellbook.

i would do something like this:

• compile the model into raw sql

• paste into dune app, comment out all code, uncomment the first phase of the model (i.e. table read with filters)

• see how that source looks in terms of row counts, etc etc

• start uncommenting more code until i notice anything that slows down the query result run time

• do similar approach on another DEX that loads into dex_solana.trades to benchmark, since we know those run pretty efficiently

  • what's different, if so? are we missing a join condition that helps performance (i.e. a block number, date partition, etc)? is there a join that truly isn't unique, i.e. exploding row count to more than expected? are we using dunesql functions that slow down performance, to force the model to output desired data (such as union distinct, distinct in selects, etc etc)

hope this helps, if you have time to assist here 🙏

edit: i would also add filters on timeframe, so the app returns things faster. then can slowly open up that timeframe as needed

Thank you for sharing how to troubleshoot this in such detail!

No worries about not being able to take a look at this yet, I totally get that you've got a lot on your plate. Really appreciate you taking the time to write out the debugging process for me.

I'll follow the steps and will either share my findings here or submit updates to the PR directly if I can identify and fix the performance issues.

Thanks again! 🙏

[0xRobin]

I'll follow the steps and will either share my findings here or submit updates to the PR directly if I can identify and fix the performance issues.

@senyor-kodi I don't think you'll be able to add to this PR as I'm the owner. Feel free to just open a new one yourself and tag us! Re-enabling the model is as easy as just removing the prod_exclude tag and adding it back to the final union.

[senyor-kodi]

@senyor-kodi I don't think you'll be able to add to this PR as I'm the owner. Feel free to just open a new one yourself and tag us! Re-enabling the model is as easy as just removing the prod_exclude tag and adding it back to the final union.

Will do that then! Thanks for letting me know @0xRobin 🙏