06:13:24 <waywardson> So, I have been encountering performance issues on my monero node that runs on HDD
06:13:48 <waywardson> it seems the number of in peers will directly cause latency on doing RPC calls
06:14:29 <waywardson> Basically, the number of in peers, assuming they are all wallets downloading the blockchain, will be the number of locations in the database that the HDD must seek to
06:15:14 <waywardson> this can quickly waste seconds in seeking time trying to do a round serving all the in peers
07:02:52 <rbrunner> Sounds about right. Just one comment: It's probably not wallets downloading the blockchain from your node, but other nodes - the "peers" that you see the number of
07:03:30 <rbrunner> Hard disks, aka "rotating rust", are notorious for being slow with Monero daemons, especially for initial syncing, which can take a loooong time with a HDD
07:04:19 <rbrunner> Everybody advices to everybody else to get a SSD as soon as possible :)
07:18:36 <elucidator> Speaking of, has anybody tried caching with solid state media while the actual database is kept on a larger spinning disk? How does that perform in such a case?
07:22:57 <sech1> It should work reasonably well, because most transactions reference only recent blocks (1-2 years old at most)
07:23:18 <sech1> So cache big enough to hold 2 years worth of transactions, will work fine
08:30:59 <vthor> "So cache big enough to hold 2 years worth of transactions, will work fine" <- this is a info should be in #monero-docs IMO
09:06:07 <elucidator> sech1: thanks
09:14:05 <sech1> But not sure if it will be enough for initial sync. Need someone to test it. It should be enough for running a synced node.
09:23:20 <m-relay> <s​yntheticbird:monero.social> iirc there was an xmr miner with an onion service that have made a detailed guide on how to use an ssd and hdd in a cache strategy with LVM for that
09:23:30 <m-relay> <s​yntheticbird:monero.social> he said it worked pretty good but I don't have the link anymore
10:32:39 <elucidator> Yeah I meant for the synched node since HDD would be bottleneck when first syncing
11:06:00 <ofrnxmr> "Speaking of, has anybody tried caching with solid state media while the actual database is kept on a larger spinning disk? How does that perform in such a case?" << yes. Ravfx
13:52:35 <RavFX> I did Caching / Tiered storage test a few month ago. Before the March stress test. It did allow to sync on an hard drive in less than a day, like 15 hours. Using only LVM2 on linux, Make a LV for the monero storage on an HDD and add a cache on the LV, to be placed on the nvme drive. Note that caching have to be configured as "write-cache" and that is important as you want the last 64GB (or whatever) of the blockchain and so you don't want "read" to
14:23:24 <elucidator> Awesome. Thanks ofrnxmr and RavFX
14:27:42 <ofrnxmr> Ravfx had a nice step-by-step guide up at one point
16:51:39 <elucidator> Per his explanation, lvm based setup should be straightforward.