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

monerod excessive hard drive writes #8189

Open
undeath opened this issue Feb 21, 2022 · 10 comments
Open

monerod excessive hard drive writes #8189

undeath opened this issue Feb 21, 2022 · 10 comments

Comments

@undeath
Copy link

undeath commented Feb 21, 2022

I noticed that monerod writes a lot of data to my drives, a lot more than what would be expected from keeping the blockchain database up to date.

Within 120h (5d) of running my monerod IO stats (reported by systemd) are: IO: 204.7G read, 407.2G written

That's an average of almost 1mb/s. Those statistics only include keeping up to date with an already synced blockchain. This does not look right.

I'm running v0.17.3.0.

@moneromooo-monero
Copy link
Collaborator

Is this while syncing historical blocks or just keeping up with new blocks after initial sync ?

@undeath
Copy link
Author

undeath commented Mar 21, 2022

just keeping up with new blocks

@moneromooo-monero
Copy link
Collaborator

Thanks. It does seem excessive then.

@moneromooo-monero
Copy link
Collaborator

moneromooo-monero commented Mar 21, 2022

Here's something you can try, to see if it changes the write amount:

<+moneromooo> OK. Do you have a setting suggestion for --db-mode to see if that is the reason for the high usage ?
< hyc> I usually suggest fast:async:1000000
< hyc> but it also won't make much difference if there's not enough RAM to cache more dirty pages
< hyc> if they can run with /usr/bin/time -v that will give full stats from getrusage()
< hyc> you'd be looking for the pagefault counts to decrease with a looser sync-mode

So: --db-sync-mode fast:async:1000000

@undeath
Copy link
Author

undeath commented Mar 22, 2022

Looking much better with that setting. Node has been running for 22h now and current stats are IO: 33.9G read, 8.4G written. Also RAM consumption is lower (now 3.7gb, before 5gb).

@moneromooo-monero
Copy link
Collaborator

Still the same after a similar time from what you originally reported ?

@undeath
Copy link
Author

undeath commented Mar 27, 2022

Yes, significantly less writes with same amount of reads. After 137h (5.7d) the process is at IO: 212.7G read, 61.9G written. RAM consumption went up again and is now at 6.1gb.

@XfedeX
Copy link

XfedeX commented Mar 27, 2022

Shouldn't the default DB config be changed?

@selsta
Copy link
Collaborator

selsta commented Mar 27, 2022

@XfedeX then we get countless complaints again that the DB corrupts on Windows.. that's why it got changed in the first place.

@hyc
Copy link
Collaborator

hyc commented Mar 27, 2022

Have considered changing the default back for everything except Windows...

moneromooo-monero added a commit to moneromooo-monero/bitmonero that referenced this issue May 5, 2023
Force sync every 100k blocks instead of every 1k blocks. Bumping this
value is reported to make a big difference in sync performance, eg:
monero-project#8189
moneromooo-monero added a commit to moneromooo-monero/bitmonero that referenced this issue May 5, 2023
Force sync every 100k blocks instead of every 1k blocks. Bumping this
value is reported to make a big difference in sync performance, eg:
monero-project#8189
SNeedlewoods pushed a commit to SNeedlewoods/seraphis_wallet that referenced this issue Mar 8, 2024
Force sync every 100k blocks instead of every 1k blocks. Bumping this
value is reported to make a big difference in sync performance, eg:
monero-project#8189
SNeedlewoods pushed a commit to SNeedlewoods/seraphis_wallet that referenced this issue Mar 8, 2024
Force sync every 100k blocks instead of every 1k blocks. Bumping this
value is reported to make a big difference in sync performance, eg:
monero-project#8189
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants