-
Notifications
You must be signed in to change notification settings - Fork 155
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
Investigate and document hardware setups that optimize disk write and lifespan #441
Comments
Been running a comparison for 4 days 23.5 hours and still seeing some nice disk write savings. These were 2 separate VM's on a single Windows 11 Client Hyper-V host. Both VM's running Windows 11 Pro, with 56 GB RAM, 6 virtual CPU's from 12th Gen Intel(R) Core(TM) i5-12600K. Was using PrimoCache software on both with a 36 GB L1 RAM Cache to minimize wear on the underlying SSD, which is a Samsung SSD 980 PRO 2TB. here's the information from node running latest: Pruning times: 2024-03-21 08:29:34.966-05:00 [INFO ] Starting Header and Block pruning... 2024-03-21 20:24:23.978-05:00 [INFO ] Starting Header and Block pruning... 2024-03-22 08:32:00.561-05:00 [INFO ] Starting Header and Block pruning... 2024-03-22 20:38:30.297-05:00 [INFO ] Starting Header and Block pruning... 2024-03-23 08:33:38.980-05:00 [INFO ] Starting Header and Block pruning... 2024-03-23 20:22:44.132-05:00 [INFO ] Starting Header and Block pruning... 2024-03-24 08:14:37.256-05:00 [INFO ] Starting Header and Block pruning... 2024-03-24 20:07:41.664-05:00 [INFO ] Starting Header and Block pruning... 2024-03-25 07:58:44.050-05:00 [INFO ] Starting Header and Block pruning... Performance metrics: And here's the data from optimization branch: https://github.com/biryukovmaxim/rusty-kaspa/tree/rocksdb-optimizations Pruning times: 2024-03-20 20:50:50.188-05:00 [INFO ] Starting Header and Block pruning... 2024-03-21 08:31:58.413-05:00 [INFO ] Starting Header and Block pruning... 2024-03-21 20:26:27.425-05:00 [INFO ] Starting Header and Block pruning... 2024-03-22 08:33:24.643-05:00 [INFO ] Starting Header and Block pruning... 2024-03-22 20:40:42.267-05:00 [INFO ] Starting Header and Block pruning... 2024-03-23 08:36:17.572-05:00 [INFO ] Starting Header and Block pruning... 2024-03-23 20:25:07.041-05:00 [INFO ] Starting Header and Block pruning... 2024-03-24 08:15:37.933-05:00 [INFO ] Starting Header and Block pruning... 2024-03-24 20:09:47.030-05:00 [INFO ] Starting Header and Block pruning... 2024-03-25 07:59:28.877-05:00 [INFO ] Starting Header and Block pruning... Performance metrics: |
I'm fully synced (running archival node) on TN11 using the new 256KB rocksdb block size. Going to let it run for a while to see if it falls out of sync or anything strange happens. I currently have 5 7200 RPM HDD's configured in a Windows Parity Storage Space (essentially RAID 5) using the Powershell below.
So 256KB interleave and 1024KB Windows NTFS Allocation Unit Size and here is the code ChatGPT gave me to alter the file "\database\src\db\conn_builder.rs" to get the 256KB rocksdb block size.
https://discord.com/channels/599153230659846165/755890250643144788/1223301320769798297 |
This config fell out of sync once the underlying size of data sourced from the spinning disks was too large. Still hunting for a spinning disk archival config that works. #441 (comment) |
Higher BPS will require significantly higher amounts of writes to storage mediums. We should document ways to optimize node setup so as to maximize disk lifespans and performance when we go to higher bps.
The text was updated successfully, but these errors were encountered: