problem: Bitcoin core needs over 16GB RAM

If you're trying to download the full blockchain, you’ll need more than 16GB of RAM. Based on what I’ve seen personally, bitcoind gets shut down by the system, and things aren't stable. I've noticed that it randomly crashes until the download finishes.

If you don't have good hardware resources to run a Bitcoin node, pruned node or full node and complete IBD, you can choose easier options with SPV wallets like Electrum wallet. SPV wallets don't need to download a full blockchain like Bitcoin Core and these wallets are lighter to use. Simplied Payment Verification Wallets (SPV wallets) Don't try to use snapshot of Bitcoin blockchain, because it can be malicious file that is used by hackers to steal your bitcoin. It's why if you run a Bitcoin node, it's strongly advised to do IBD by yourself.

I don't read French, but I can tell you from personal experience that Bitcoin Core can do a full IBD on Ubuntu with 8 GB RAM. 16 GB is much better though, and in that case I'd use dbcache=8192 to reduce disk writes. You're going to have to provide more log details to find why it's consuming so much RAM.

As stated by other member on your previous thread, you could adjust dbcache value based on your total RAM and how much RAM used by OS and other application you run. For example, you have 16GB RAM where 6GB used by OS and other application you run. In this case, i could recommend dbcache=7168 leaving 3GB as reserve.

Here is the journalctl of the kill ;

Try reducing your database cache size in bitcoin.conf: Alternatively, you can swap space with the disk, but note that this is going to result in an extremely slow IBD, especially if your disk is HDD. BTW, have you confirmed it's RAM the problem? Check how much RAM is used and left. In linux:

Thank you, the IBD is over, now i'm more quiet. But i have just a kill now

You really should not try to download the entire blockchain using a HDD, it will take literally weeks. Do it on an SSD. After that just copy the entire thing over to your HDD. You'll save weeks.

At this point, you might want to use advance monitoring software to find out how much RAM is used and which application use most RAM on specific date and time. After all, Bitcoin Core shouldn't use that RAM.

i agree.

Sunday morning I updated my unpruned Bitcoin Core node that runs 24/7 on my home desk laptop to version 27.1 (Ubuntu 22.04.5 LTS; 8GB RAM; Lenovo Thinkpad T520). Core runs as server daemon in the background and monitors a loaded watch-only wallet with nearly 22k descriptors and connects via Tor to other nodes. I'm used to have a terminal window open where Core's debug.log is displayed and updates new entries immediately. I have certain keywords of interest highlighted in that view, at minimum I see new blocks and any transactions related to my watch-only wallet. Other memory related settings in my bitcoin.conf file for this node are (dbcache is default, ie. 450MB): The Ubuntu installation isn't fat, filesystem on a 1TB SATA SSD is encrypted, I've installed different browsers, GIMP and a few other apps that I regularly need. Usually I have mostly Firefox open when I do my daily browsing or look clips on Youtube or watch a movie stream. I don't open a lot of apps simultanously. After an uptime of bitcoind of nearly three days (~220,000 seconds) and with Firefox open (I have quite some tabs open that are retained during sessions), this is the memory consumption output by free -h: I don't see much memory pressure when about 5+GiB are still allocated as buffer/cache by the kernel and ~5GiB are flagged as available. I scanned through output of journalctl and couldn't find anything related to systemd-oomd in my logs. I guess the out-of-memory daemon is bored to death on my system. I take this as a good sign...

You're only 2 or 4 screws away from adding 8 GB more I never liked that 2.2 GB swap when it has enough memory, and used to run without swap, but enabled it again just in case some process suddenly needs a lot of memory (like Firefox on Aliexpress). That gives me more time to respond instead of becoming dead slow until it kills something.

Thanks for sharing. Although in this case, more advance monitoring tools such as atop could show more data. For example, showing RAM usage over time and top 3 process which use most memory. Here's a snipped example from my VM. You could change the behavior by modify swappiness value.

Haha, yes I know, it's fairly easy and only 4 screws in total if you have to access both RAM slots. I only buy used business laptops that are easily serviceable on purpose. I'm cured from hassles with some consumer laptops I had to open and service... IIRC, my T520 might have two 4GB SODIMMs, but I will check next time I dust off the internals. I'm not too keen to update this particular device as I have other more recent laptops which are likely more power efficient than this one and are scheduled to replace this one. But as long as it's running fine and doesn't cause me issues, I don't feel much pressure to act. That's true and ABCbits hints to tweak swapiness accordingly. I remember having done this for one of my Raspi 4B nodes, but that was quite some time ago and I forgot about this tuning. It doesn't bother me enough, though. So much to tweak, so little time. Getting back to topic, I highly doubt that Bitcoin Core 27.1 (or earlier versions) really needs 16GB RAM or more, even when performing IBD. If you have inappropriate option settings, it can demand too much. But then it's mostly your fault to ask for too much memory if e.g. your dbcache value is way too high. Memory pressure also depends on other software running on your system and we didn't read much about this so far from OP. During IBD Bitcoin Core will of course benefit from more RAM if that RAM is actually available without causing other issues. Set your options wisely and with understanding.

You must be running Bitcoin Core on the GNOME desktop. GNOME is known to be very resource-intensive by itself and it wouldn't surprise me if it used 4 GB, about half of your RAM, by itself. However, Bitcoin Core running with no desktop can sync with 8 GB just fine - I am doing it right now actually (well, with 16 GB, but that is because I am running about 4 other nodes simultaneously. At any rate, RAM usage is about 50%)

I tested running Bitcoin-Qt on my daily Ubuntu machine with 8GB RAM instead of running Bitcoin Core as bitcoind without GUI. Memory consumption looks almost the same to me after nearly 24h continuous running of Bitcoin-Qt. I've installed atop package and run it as a service. Need to become more familiar with it, yet. On startup the GUI needed considerable time to "load" my default watch-only wallet (21954 descriptors or so-called Patoshi blocks and some tenthousands of transactions) and show the wallet's overview/balance and be able to display the wallet's transactions. I left Bitcoin-Qt do its thing while browsing with Firefox and didn't measure after what time the GUI was usable. In fact, from debug.log it takes only ~5.5s to load the wallet, but considerably longer if you ask for the final balance and display a list of all known transactions. If of interest, here are some parts from debug.log from the Bitcoin-Qt startup: For the GUI to be fully responsive, AFAIR it took longer than initload thread exit at 14:43 UTC. While the GUI was still crunching on "loading/preparing" the wallet's details, I could see in debug.log that block sync and wallet's transactions sync was already in normal progress. This node wasn't far from blockchain tip, anyway.

I have tinkered a LOT with the various memory options in bitcoin-core on both my Synology NAS and a Pi5 8GB on Bookworm. The daemon seems to run under 10% cpu while getting the blockchain on the Pi5. My issue is no matter what I do the free memory drops to under 300, and the swap does the same. It doesn't crash it so far, but I'm trying to get a handle on whats going on. I can't see a thing in top to explain it. I had the daemon running on my Synology, and it had far more issues with cpu load than memory. I have been chipping away since Thanksgiving trying to finish the initial IBD. I can reduce all memory options to minimums, or not, but eventually all of the memory becomes allocated. It's worth mentioning that I am running bitcoin-node-manager in nginx as well, and 95% of the time it times out trying to display the report. bitcoin-cli very often also times out trying to display info also. Top says bitcoin is under 10% memory use. I'm running glances and that says  swap is at 65%, and I get frequent IOwaits, but they don't pile up. I suppose what bugs me is I can't seem to restrict bitcoin memory use with any setting. I have tweaked these numbers up and down a LOT and nothing seems to matter. I should be able to slow it to a crawl and see hardly ant memory used, then adjust up to a sensible level. But it doesn't seem to work that way. The Pi is aarch64 and the Synology was x86. root@pi5:~# cat /etc/bitcoin/bitcoin.conf daemon=1 blockfilterindex=1 dbcache=225 maxmempool=50 maxuploadtarget=128 maxconnections=75 maxorphantx=10 printtoconsole=1 disablewallet=0 walletrbf=1 txindex=1 testnet=0 rest=1 server=1 pid=/run/bitcoind/bitcoind.pid edit: I changed to run level 3 (multi-user) and this: daemon=1 blockfilterindex=1 dbcache=4096 blocksonly=1 v2transport=1 maxmempool=300 maxuploadtarget=5000 maxconnections=40 maxorphantx=10 And so far it looks like swap issue solved. I am curious what the limiting factor is now in IBD speed. The cpu load hovers around 2%. Is it peer availability?

Isn't this just your kernel trying to free up as much memory as possible for file cache, while it's swapping away anthing that's not used? From experience, your limit is probably disk speed. Bitcoin Core reads and writes terabytes of data during IBD with only 8 GB RAM.

My last (sort of) "benchmark" that I did to check how fast a Raspi 4B with 8GB RAM can perform an IBD is from June 22nd, 2023 with Bitcoin Core v25.0.0. For reasons I didn't keep memories of, I had to delete the bitcoin container and some more cleanup on my Umbrel node. As far as I remember, I deleted any blockexplorer containers, the Electrum server container, basically all stuff that could possibly eat up significant performance. I set dbcache=5120 in Umbrel and started the IBD, no old blockchain data was left from the previous deletion of the Bitcoin Core container in Umbrel (I checked). My internet connection has stable 110MBit/s downstream and ~40MBit/s upstream; Umbrel connects via Tor and I2P only; storage media was a Samsung 860 SATA SSD connected with an USB3-SATA-interface supporting proper UASP protocol. Other notable config options were (not all are listed here): IBD ran uninterrupted from 2023-06-22T18:00Z until 2023-06-26T16:46Z when it reached progress=1.000000 at blockheight 796033. That's little less than 95h, not bad for a Raspi 4B. During IBD I didn't login to the Umbrel webinterface, only checked progress once or twice a day via SSH login and peeking into Core's debug.log file. My question to OP: what's your goal, as fast as possible IBD or what else? How is your storage attached to your Pi5? With a Pi5 (I still don't have one, waiting for the CM5 module with 16GB RAM that was announced recently) I would use a M.2 NVMe SSD adapter board which gives way faster mass storage transfer rates than a Pi4 could ever dream of. You didn't say anything regarding your Pi5's mass storage. Consider also option blocksonly=1 during IBD, so your node doesn't have to bother with mempool and transaction verification.