Files
bitcoin/doc/reduce-memory.md
Ava Chow 11ebbd9072 Merge bitcoin/bitcoin#28463: p2p: Increase inbound capacity for block-relay only connections
c11508406e doc: Update docs that refer to -maxconnections (Martin Zumsande)
69ce0dba2a test: add test that EvictTxPeerIfFull only evicts tx-relaying peers (brunoerg)
3ed7f06418 p2p: trigger possible eviction if we support bloom filters and change a peer to tx relay (Martin Zumsande)
0bd3d3dfa5 init: make inbound tx relay percentage configurable (Amiti Uttarwar)
cc59aee196 test: add functional test for inbound maxconnection limits (Amiti Uttarwar)
1b76e04736 net: increase inbound capacity for block-relay-only connections (Martin Zumsande)
87bca1c2ad net: add options to AttemptToEvictConnection (Martin Zumsande)

Pull request description:

  This is joint work with amitiuttarwar.

  See issue #28462 for a broader discussion on increasing the number of block-relay-only connections independent of this particular implementation proposal.

  We suggest to increase the number of inbound slots allocated to block-relay-only peers by increasing the default maximum connections from 125 to 200, with 50% of inbound slots accessible for tx-relaying peers.
  This is a prerequisite for being able to increase the default number of outgoing block-relay-only peers later, because the current inbound capacity of the network is not sufficient.
  In order to account for incoming tx-relaying peers separately from incoming block-relay peers, changes to the inbound eviction logic are necessary.

  See the next post in this thread for a more detailed explanation and motivation of the changes.

ACKs for top commit:
  instagibbs:
    ACK c11508406e
  achow101:
    ACK c11508406e
  dergoegge:
    crACK c11508406e
  marcofleon:
    ACK c11508406e

Tree-SHA512: c71e1481eb235429a6c9d7ce771c7bf825f850b135e904ccfa3505112628fef4188b560d0be0847c968e5ece43c1518590069b7e6e2480790d3ef1ce07d1ac38
2026-07-24 14:30:00 -07:00

4.1 KiB

Reduce Memory

There are a few parameters that can be dialed down to reduce the memory usage of bitcoind. This can be useful on embedded systems or small VPSes.

Swapping

When the operating system is under memory pressure, it may swap memory pages from RAM to disk. If this becomes continuous ("thrashing"), bitcoind can slow to a crawl, especially during initial sync or reindex.

If you see sustained swap I/O while bitcoind runs, restart with a lower -dbcache. If needed, also reduce -maxmempool, -maxconnections, or use -blocksonly. Bitcoin Core may warn at startup when -dbcache looks too large for the detected system memory.

In-memory caches

The size of some in-memory caches can be reduced. As caches trade off memory usage for performance, reducing these will usually have a negative effect on performance.

  • -dbcache=<n> - the UTXO database cache size, this defaults to 1024 (or 450 if less than 4096 MiB system RAM is detected). The unit is MiB (1024).
    • The minimum value for -dbcache is 4.
    • A lower -dbcache makes initial sync time much longer. After the initial sync, the effect is less pronounced for most use-cases, unless fast validation of blocks is important, such as for mining.

Memory pool

  • In Bitcoin Core there is a memory pool limiter which can be configured with -maxmempool=<n>, where <n> is the size in MB (1000). The default value is 300.

    • The minimum value for -maxmempool is 5.
    • A lower maximum mempool size means that transactions will be evicted sooner. This will affect any uses of bitcoind that process unconfirmed transactions.
  • The unused memory allocated to the mempool (default: 300MB) is shared with the UTXO cache, so when trying to reduce memory usage you should limit the mempool, with the -maxmempool command line argument.

  • To disable most of the mempool functionality there is the -blocksonly option. This will reduce the default memory usage to 5MB and make the client opt out of receiving (and thus relaying) transactions, except from peers who have the relay permission set (e.g. whitelisted peers), and as part of blocks.

    • Do not use this when using the client to broadcast transactions as any transaction sent will stick out like a sore thumb, affecting privacy. When used with the wallet it should be combined with -walletbroadcast=0 and -spendzeroconfchange=0. Another mechanism for broadcasting outgoing transactions (if any) should be used.

Number of peers

  • -maxconnections=<n> - the maximum number of connections, which defaults to 200. Each active connection takes up some memory. This option applies only if inbound connections are enabled; otherwise, the number of connections will not be more than 11. Of the 11 outbound peers, there can be 8 full-relay connections, 2 block-relay-only ones, and occasionally 1 short-lived feeler or extra outbound block-relay-only connection.

  • These limits do not apply to connections added manually with the -addnode configuration option or the addnode RPC, which have a separate limit of 8 connections.

Thread configuration

For each thread a thread stack needs to be allocated. By default on Linux, threads take up 8MiB for the thread stack on a 64-bit system, and 4MiB in a 32-bit system.

  • -par=<n> - the number of script verification threads, defaults to the number of cores in the system minus one.
  • -rpcthreads=<n> - the number of threads used for processing RPC requests, defaults to 16.
  • -prevoutfetchthreads=<n> - the number of threads used to fetch block input prevouts, defaults to 8.

Linux specific

By default, glibc's implementation of malloc may use more than one arena. This is known to cause excessive memory usage in some scenarios. To avoid this, make a script that sets MALLOC_ARENA_MAX before starting bitcoind:

#!/usr/bin/env bash
export MALLOC_ARENA_MAX=1
bitcoind

The behavior was introduced to increase CPU locality of allocated memory and performance with concurrent allocation, so this setting could in theory reduce performance. However, in Bitcoin Core very little parallel allocation happens, so the impact is expected to be small or absent.