Skip to content
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

High memory usage with V14 Metadata and Extrinsics #434

Open
insipx opened this issue Jan 27, 2022 · 0 comments
Open

High memory usage with V14 Metadata and Extrinsics #434

insipx opened this issue Jan 27, 2022 · 0 comments
Labels
bug Something isn't working difficulty-hard Issues that effect much of the codebase and might be difficult to resolve needs-investigation This issue needs more info/investigation on what exactly to do p1 Priority 1 type-decode

Comments

@insipx
Copy link
Collaborator

insipx commented Jan 27, 2022

Running Archive off the current master (b5ee4d6) results in a high memory usage once blocks utilizing V14 metadata begin execution. The memory issue can be seen from this graph of memory gathered

image

At some point archive just crashes after oom error.

AFAICT from my debugging the reason for high memory usage as v14 is reached is because documentation is stored along with metadata. So when subxt decodes an extrinsic, it comes with all the associated metadata for those functions attached. This results in many extrinsics being held pre-postgres-insertion in memory with a high amount of extraneous text included.

Included is a query on the extrinsics table while running node-template. We see that each extrinsic has the same docs attached for 'Timestamp' -- this would be the same for every extrinsic ever executed V14+.
Screen Shot 2022-01-27 at 10 35 52 AM

This is definitely redundant since the metadata docs can be stored once in a separate table

Even before V14 blocks are reached, memory is on a slow-uphill climb trending towards 10GB. This memory issue is more ambiguous and I haven't found one single cause. Things that I have tried investigating:

  • Messages sent between actors use unbounded queues and could be a source of lots of data getting backed up somewhere
  • Tasks in archive range in speed; EX: Loading blocks from rocksdb is much faster than executing them. These differences in indexing speed could cause memory issues somewhere in the messages sent between actors. This was partly solved through the use of rabbitmq which relieved some previous memory performance issues
  • RocksDB might be a source that uses lots of memory; at some point it would be worth experimenting with paritydb to see if this relieves memory issues (whenever/if that is integrated into archive)
@insipx insipx added bug Something isn't working difficulty-hard Issues that effect much of the codebase and might be difficult to resolve needs-investigation This issue needs more info/investigation on what exactly to do p1 Priority 1 type-decode labels Jan 27, 2022
@insipx insipx pinned this issue Jan 27, 2022
@jsdw jsdw unpinned this issue Jul 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working difficulty-hard Issues that effect much of the codebase and might be difficult to resolve needs-investigation This issue needs more info/investigation on what exactly to do p1 Priority 1 type-decode
Projects
None yet
Development

No branches or pull requests

1 participant