Skip to content

Hardware

Eric Voskuil edited this page Jan 5, 2018 · 12 revisions

Storage Device

BS uses memory-mapped files to achieve high performance disk I/O. This works with a hard disk drive (HDD) but is optimized for a solid state drive (SSD), which is highly recommended.

Storage Space

As of March 2017 the mainnet blockchain requires 115 GB of disk space. Absent consensus changes the blockchain will grow at a rate of about 4.4 GB per month. In other words blockchain storage grows at a rate of 53 GB per year. In 5 years the chain will be about 375 GB. With full address indexing the server requires a little more than double the storage space of the blockchain (full node). So in 5 years a fully-indexed server will require about 780 GB. The market price for SSD storage (HHD prices are about 35% lower) of the fully-indexed chain is about $100 and in 5 years will be about $7.00 despite chain growth.

Space must must also be allowed for expansion while running, based on the configuration setting file_growth_rate. The configured growth rate can be reduced as the files get larger. So for example a fully indexed store of 240 GB configured with a 4% growth rate would require 250 GB. The store should not be allowed to hit the space limit as an expansion attempt will cause process termination with store corruption.

Log files require additional storage space. Growth can be rapid with verbose logging enabled. Logs should be stored on an SSD and may be rotated to other storage after reaching a configured size.

Memory

A significant amount of testing has been performed at 8 GB RAM on all supported operating systems, with good results. Best performance is achieved with RAM sufficient to store the entire database, as paging costs approach zero. At 8 GB RAM configuring database.cache_capacity = 10000 is recommended. At 128 GB RAM or more a cache capacity of zero is optimal.

Processors

A significant amount of testing has been performed with 4 cores on all supported operating systems, with good results. The node is designed to fully utilize all cores to the extent possible. The number of cores can have a significant impact on block and transaction validation performance. Excellent performance is achieved with 16 cores, while best performance is typically achieved in the neighborhood of 32 cores, although with certain blocks we have seen 64 cores fully utilized.

Bandwidth

With a high end machine bandwidth will become the limiting factor in performance of initial block download. A gigabit connection should be able to download the blockchain in 15 minutes once parallel initial block download is enabled.

File Handles

There are no expected problems resulting from default operating system file handle limits.

Clone this wiki locally