go
go copied to clipboard
captive-core usage of minimal.db should be controlled by the user
What problem does your feature solve?
if CAPTIVE_CORE_USE_DB is set captive-core resets it's database to genesis ledger on every start, then has to rebuild everything, even if it has a perfectly fine 5 mins old 19GB database on disk/ramdisk.
if CAPTIVE_CORE_USE_DB is not set, then stellar-core is called with --in-memory. By my experience the minimal.db is used only if in --in-memory mode.
I measured disk IO with the database on disk, and I observed there is no real demand from stellar-core. 99% of the time the disk is used by postgresql. My conclusion is: it is a lot better to have the 20GB database on disk, or on compressed ramdisk, or in compressed ramswap (note that the 20GB sqlite database can be compressed into 5GB in realtime with these methods), anywhere but not in memory (it's waste of resources), and tune postgresql to use the freed memory instead.
Trying to keep this evergrowing database in memory is not sustainable.
What would you like to see?
Have a new horizon env variable CAPTIVE_CORE_USE_MINIMALDB and let the user decide about the usage of minimal.db Catch up using checkpoints. Handle the minimal db, and know where to pick up from on restart regardless of captive-core database storage method. (just like in --in-memory mode)
What alternatives are there?
Maybe do not reset the stellar-core database to genesis ledger, drop every table, then restart captive-core, on every horizon startup, but let stellar-core catch up on its own.
Is there a way to force horizon not to reset captive-core's database to genesis ledger on every horizon startup, regardless of the --in-memory parameter?