My Bitcoin Core app is syncing very slowly (3-5 minutes per block) and RPC and Sync keep timing out. I notice in the Kernel log that the Ethernet bridge device keeps cycling through the following states every minute or two:
2024-10-01T08:20:38-07:00 device veth4 entered promiscuous mode
2024-10-01T08:20:38-07:00 IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
2024-10-01T08:20:38-07:00 IPv6: ADDRCONF(NETDEV_CHANGE): veth4: link becomes ready
2024-10-01T08:20:38-07:00 br-start9: port 5(veth4) entered blocking state
2024-10-01T08:20:38-07:00 br-start9: port 5(veth4) entered forwarding state
2024-10-01T08:21:56-07:00 br-start9: port 5(veth4) entered disabled state
2024-10-01T08:21:56-07:00 device veth4 left promiscuous mode
2024-10-01T08:21:56-07:00 br-start9: port 5(veth4) entered disabled state
2024-10-01T08:22:16-07:00 br-start9: port 5(veth4) entered blocking state
2024-10-01T08:22:16-07:00 br-start9: port 5(veth4) entered disabled state
2024-10-01T08:22:16-07:00 device veth4 entered promiscuous mode
2024-10-01T08:22:16-07:00 IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
2024-10-01T08:22:16-07:00 IPv6: ADDRCONF(NETDEV_CHANGE): veth4: link becomes ready
2024-10-01T08:22:16-07:00 br-start9: port 5(veth4) entered blocking state
2024-10-01T08:22:16-07:00 br-start9: port 5(veth4) entered forwarding state
2024-10-01T08:23:23-07:00 br-start9: port 5(veth4) entered disabled state
2024-10-01T08:23:23-07:00 device veth4 left promiscuous mode
2024-10-01T08:23:23-07:00 br-start9: port 5(veth4) entered disabled state
2024-10-01T08:23:42-07:00 br-start9: port 5(veth4) entered blocking state
2024-10-01T08:23:42-07:00 br-start9: port 5(veth4) entered disabled state
2024-10-01T08:23:42-07:00 device veth4 entered promiscuous mode
The StartOS machine is running as a VM in TrueNAS (8GB RAM, 4 CPUs), and it’s getting a separate DHCP IP address from the Router on the wired port shared with the TrueNAS host system. (Latest StartOS and Bitcoin Core 27.1.0) The occasional .onion host is showing as not reachable in the Bitcoin logs, but there’s nothing else in the logs that might indicate why it’s taking so long to download and verify the blocks.
The server was down for a while, and now I’m 8 months behind in the blockchain, and at this rate it will take another 6-8 months to catch up. Any ideas why it’s so slow and what to do about it? CPU utilization and temperature are all reasonable. The network utilization shows a bump every time a new block is downloaded, but the utilization doesn’t max out the network, either.
It sounds like your Bitcoin Core sync issue may be influenced by several factors, such as network configuration, resource allocation, and potential connectivity problems with Tor or other peers. Let’s break it down and troubleshoot:
1. RAM & CPU Resources:
8 GB RAM and 4 CPUs are relatively modest for syncing a full node, especially when catching up on a large number of blocks. Bitcoin Core is resource-intensive, particularly during the initial sync.
Solution: If possible, try increasing the allocated RAM and CPU cores. Bitcoin Core can benefit from additional CPU cores during syncing, especially for verifying blocks. Additionally, you can increase the Database Cache in the Bitcoin configuration under Advanced settings during the sync process. The default is 450 MB, so consider raising it to optimize performance.
2. Disk I/O Bottlenecks:
TrueNAS VM could be experiencing disk input/output (I/O) bottlenecks, particularly if other processes on TrueNAS are also consuming disk resources.
Solution: Ensure the VM has access to fast storage (SSD is highly recommended). Slow disk performance could significantly hinder syncing speed, especially when verifying blocks.
3. Tor Connectivity Issues:
You mentioned .onion hosts showing as not reachable. This could be slowing down your node’s ability to connect to peers, as Tor connections may be less reliable or slower than clearnet.
Solution: Open your Bitcoin configuration > Advanced > Peers and ensure that the setting for “Disable clearnet” is set to false. This allows your node to connect to both Tor and clearnet peers, which can improve your node’s ability to sync with the network. Having access to clearnet peers can provide a more stable connection and potentially speed up the synchronization process.
4. Peer Connections:
Sync speed is largely dependent on the number of connected peers and the bandwidth they provide. A small number of slow or unreliable peers (e.g., those connected via Tor) could slow down the sync process.
Solution: Check how many peers Bitcoin Core is connected to If it’s low, consider opening more inbound ports (if possible) or explicitly adding fast peers via addnode in Config > Advanced > Peers.
By addressing these areas, you should be able to improve the sync speed of your Bitcoin Core instance significantly. Let me know how it goes!
I increased CPUs in the VM to 8, and changed the Database Cache to 4000MB. I also added 2 static peers and allowed clearnet connections. Unfortunately, there’s not much I can do about the storage speed or adding RAM at this time. It was working better several months ago before my NAS boot drive failure. After I restored the TrueNAS boot drive, the only change on the system was to upgrade the StartOS and apps. TrueNAS version and hardware has not changed. After all this, the sync performance remains unchanged at 1 block every 3-5 minutes and keeps showing “Timed Out. Retrying soon…”
I did replace my home router with an OpenWRT box. Are there any known issues that could be blocking connections here?
Looking at the service properties, it only shows 2 or 3 peers connected. Tor logs show that Tor is staying up and is making and receiving connections and sending and receiving data. So it looks like it’s a network problem where the service is not making (or keeping open?) enough peer connections.
Bitcoin Core has certain hardware requirements in 2024 that you’re just not meeting. Nothing you do with configurations beyond not meeting those requirements is going to help.
Your very low RAM, on a slow processor with what are probably spinning magnetic disks… can’t run Bitcoin. The low number of peers is because the peers can’t connect to you, and they can’t connect to you because your Bitcoin doesn’t respond because it’s not running all the time.
So this can’t be entirely true, because after letting it go for many weeks where it would process 1 block every 3-10 minutes, it’s processing 2-3 blocks per minute right now. The machine is capable (AMD Ryzen 5 PRO 4650G with 12 threads, with 8 vCPUs assigned to the startOS VM), and I can see it working with high CPU usage and making good progress as I am writing this. Why would the same physical machine running the same VM that synced the entire blockchain in a few days in 2023 be unable to do the same in 2024? My whole question is what was blocking it from doing this before right now? The only thing I could see in the logs before was that peers were not staying connected and the virtual ethernet ports were making weird state transitions.
Are you asking why you could quickly sync and verify less than 8GB of UTXOs in 2023 with 8GB of RAM, and in 2024 you can only slowly sync more than 8GB of UTXOs with 8GB RAM?