Witness_node Memory Management Discussion

[abitmore]

This ticket is for discussing potential optimization on memory management of witness_node.

Currently, 5 months after BTS 2.0 launch,

• head_block_num is about 4,300,000,
• a typical witness_node running in Windows 7 64 bit uses about 2GB of memory (physical+virtual),
• a typical witness_node running in Ubuntu 14.04 LTS amd64 uses about 2GB of memory as well (VIRT>2,000,000 and RES=1.16g on one of my node).

Perhaps we'll have to face scalability issues rather soon.

Ideas?

[theoreticalbts]

Originally BitShares was created with architecture of core (bare minimum needed for validation) and plugins (containing data not needed for validation, e.g. operation history). As time went on, more and more code stopped following this architecture. There's a lot of stuff in the core that needs to be moved to a plugin.

For example:

• Block producing witnesses need not track operation history at all
• Single-user wallets need only track operation history for user's account
• Hosted wallets need to track all operation history

Related: #246 #422 #571

As a large portion of the objects are never modified, as a stopgap you can simply run the witness node on a system with a large swap file.

[abitmore]

Using larger swap file seems to be a good idea. However, when a swapped out object need to be read (but not be modified), it still need to be swapped in, this will more or less affect performance.

We need analysis to show what objects are in memory, how big is each of them, how useful is each of them etc. As @theoreticalbts mentioned, market history is one of useless objects for block producers.

[pmconrad]

The "large swap" idea may not work if rarely used objects in memory are interleaved with often-used objects. A single often-used object in a memory page will effectively lock that page in RAM.

[vikramrajkumar]

This issue was moved to bitshares/bitshares-core#192