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

[WIP] Decrease chain indexes RAM usage using Optional values #2794

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Liquid369
Copy link
Member

Redoing of #2315

Some users have noticed with 5.5 theres a need for some optimization, while hunting it down also figured to bring back this to assist in daemon optimization

Explanation from prior PR:

This PR migrates two uint256 fields, that aren't needed to be initialized for every block index that ever existed, to optional values. Only initializing them in the lapse of time where the data is/was available.

  1. The zc accumulator checkpoint: added to the header in the block version 3 and was active up to block version 7.
  2. The sapling tree root hash: added to the header in block version 8.

@zkbitcoin
Copy link

zkbitcoin commented Jan 26, 2023

will post here findings from Valgrind (idea is to attack why 5.5.0 CPU usage has gone up noticeably over 5.4.0) in the addition to RAM

./configure -enable-debug then have it all synced up , htop will show one CPU thread being utilized constant (that shouldnt be all should have very low utilization unless disk I/O or stake found etc) and even on stake found should not be so bad

https://developer.mantidproject.org/ProfilingWithValgrind.html

@Liquid369 Liquid369 changed the title Decrease chain indexes RAM usage using Optional values [WIP] Decrease chain indexes RAM usage using Optional values Jan 26, 2023
@Liquid369
Copy link
Member Author

Needs rebasing on a newer base, will maybe close later

@zkbitcoin
Copy link

too much machine info in the valgrind (attaching screenshot) best is to run

valgrind --tool=callgrind --dump-instr=yes --simulate-cache=yes --collect-jumps=yes ./pivxd

and then

kcachegrind (qcachegrind on Mac)

looks like ProcessMessage event loop consumes most CPU (also PeerLogicValidation also ProcessMNWinner)

maybe no enough breathing room is given there (like sleep yield etc), result is one CPU thread is stuck on 100% even when no new block is coming in

debug

@zkbitcoin
Copy link

zkbitcoin commented Jan 27, 2023

moved "CPU issue" to separate ticket as this ticker refers to RAM usage (could be related but its better to separate)

#2795

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants