08:48:58 Won't clog this channel with the actual post, but if anyone's interested in getting paid in Monero to work on a privacy-focused cloud computing startup check out #monero-community-dev:monero.social 13:35:03 Could anyone tell me their though about replacing LMDB by HSE (https://github.com/hse-project) to store the blockchain in the monero node. (performance speaking, do not talk about effort i don't need to sleep). 14:04:19 I doubt anyone will be able to guess performance differences but I don't think there's much interest in replacing LMDB. 14:36:22 LMDB is extremely slow especially for hard drives. I would love to see Monero switch to a faster database such as LevelDB. This is a good blog post by Mozilla which compares the two databases: 14:36:22 https://mozilla.github.io/firefox-browser-architecture/text/0017-lmdb-vs-leveldb.html 14:41:28 According to https://github.com/mykmelez/kvbench, LevelDB is much faster than LMDB for reading and writing, and it uses less disk space; the disadvantage is that opening the database is much slower for LevelDB 14:48:25 "LevelDB is widely noted for being unreliable and databases it manages are prone to corruption." -> from your mozilla link 14:50:09 lol 15:08:55 xfedex[m]: https://github.com/laanwj/bitcoin/tree/2016_04_mdb bitcoin uses leveldb and an experimental lmdb implementation showed over 40% speedup in sync 15:18:48 and optimizing for HDD instead of SSD in 2023 is exactly the opposite of what we should be doing lol 15:41:09 It's kinda annoying that monerod syncs 0.3 blocks per second on an HDD thought 15:44:10 Buy an ssd. They are < 100 15:45:38 Wow. That's very rare! Only 100 people can ever get a whole SSD! 15:46:09 lol 16:39:28 Just fit the blockchain in RAM, it's not that big! Then push it to HDD at the end 16:48:28 RavFX is doing some interesting experiments with fast syncing to HDD with SSD acting as a cache: https://m-h-o-l.org/index.php?article=hdd_sync 16:49:05 IIRC some aggressive OS-level caching settings can help with syncing on HDD 16:49:18 ^^ http://waw7epjul5xeacm4niblpgihdtg3atxyqekrlgz5spynqosdzftnbfad.onion/index.php?article=hdd_sync 16:49:57 ArticMine @ArticMine:libera.chat: hyc: 17:09:16 don't have my tor browser handy at the moment 17:09:37 but the usual stuff I would do: run monerod async, no fsyncs at all 17:09:58 set /proc/sys/vm cache params: writeback 10 minutes 17:10:17 dirty_ratio 60% or more (I usually use 90%) 17:10:25 dirty_background_ratio 60% 17:11:12 that will keep most writes in RAM, and OS will flush whenever things get full 17:12:45 Yeah, if you have a lot of ram ( >=32GB ) 17:12:45 adjusting the vm cache work 17:12:45 Except that this cache is gone after a reboot. 17:12:45 It's fine if you sync one shot then leave monerod running full time (at least, for now) 17:12:50 same strategy isn't available on Windows, the cache tuning params onlu existed in win2k. they were still present in winXP but no-opd 17:13:52 also not viable for windows simply because the OS isn't that reliable, and a crash will leave a corrupted file 17:15:27 I did have corrupted monero lmdb on Linux after a crash, two times so far. Probably file system & vm cache settings dependent. 17:18:18 hyc: this is the clearnet link 17:18:37 yes, need a FS that guarantees ordered writes, like ext3 / ext4 17:19:48 this is already noted in the LMDB docs. all known since LMDB was created in 2011. 17:19:55 Yep. 17:19:56 I have XFS everywhere here. Not testing new CPU/RAM overclocking when monerod is running 17:20:06 ofrnxmr[m]: where? 17:20:28 https://m-h-o-l.org/index.php?article=hdd_sync 17:20:38 Sorry. Forgot the link 😅 17:20:46 heh 17:23:00 using a persistent cache is great, yeah 17:23:32 Optane was quite promising on those lines 17:23:57 too bad Intel axed it. the write endurance never lived up to claims. 17:25:20 You should already have read the benchmarks across different filesystems https://www.symas.com/symas-lmdb-tech-info 17:25:29 xfs doesn't do so great 18:17:59 pas * 18:18:31 Wrong keyboard...