Current minimum specs for a vNode

[Josh_Hamon]

Other than:

@Jared

4 CPUs, 4 GB Ram and 50 GB SSD

I’m not actually sure, what are the minimum specs for a vNode? Bonus points for specs for multiple vNodes on a single vm.

[Jared]

I would just like to point out that I quoted those figures from an out of date guide.

edit: One of my nodes that is fully synced is at 96 Gb.

[fredlee]

Yeah 50 GB is way too low. Your validator may use less at the start, because it will only sync shards where it has been selected as a committee. Theoretically you would end up with a full node eventually, but since the selection is random, there’s no way to tell.

Here’s a list of current shard data from a full node, it is 149GB right now, but it is increasing quite fast. I would not build a vNode with less than 200GB. To be sure, you should go with 500GB SSD if it is a physical machine you are building, because that is what the pNodes were shipped with.

23G	beacon
36G	shard0
14G	shard1
11G	shard2
18G	shard3
11G	shard4
10G	shard5
15G	shard6
15G	shard7

As you can see, if you get selected for shard5, then the beacon and shard data will only take 33GiB. But if you get selected for shard0 after that (33GiB + 36GiB) you’re already over the 50GiB.

Requirements for multiple nodes on the same machine, is really hard to tell. When you’re outside of committee the nodes are practically idle and use very little resources. But if you’re unlucky, all nodes could be selected at the same time.

I found the only way to know is to test it, so I’m currently running 1 full node and 12 validators on a Mac mini from 2012. It’s a quad core i7 with 16GB ram. It misses 2-3% of the votes from time to time, but I actually think it’s temporary network issues when that happens. That is however well above the risk of getting slashed.

When it comes to memory, you should calculate at least 1GB per running node.

[adrian]

Per vnode, in most cases you would be fine with: 0.5 CPU idle, 2-3 CPUs when syncing, 1-2GB RAM, 200GB SSD, at least 10mbit/s (<5ms ping) network connection.

The biggest bottleneck on sync speed is the SSD write speed, as incognito writes many small leveldb files, so opt for high speed NVMe when possible.

[Josh_Hamon]

Is there an official answer @Support?

[duc]

Hey @Josh_Hamon,
I believe that @adrian and @fredlee are experienced node operators, they managed to maintain many nodes working fine all-time (except sometimes their nodes got issues due to my fault with the new code release) so the specs they gave are quite reasonable and they were from the real/current situation of the network.

I guess the only concern now is about the growth of required disk size so I gave an answer for it in the Slashing topic.

Introducing Slashing V2

Hey guys, let me clarify a bit about the disk space issue and how we can solve it. In the topic, as we mentioned, Staking Flow V3 will be introducing the Sync phase but apart from Sync phase, it will also change flow once a node is swapped out of a committee. Basically, in the current flow, after a node is swapped out, it will be randomly assigned to a shard in the next selection round that may lead the node to sync all shards like a fullnode in long run. So to get rid of the situation, after …

@adrian

The biggest bottleneck on sync speed is the SSD write speed, as incognito writes many small leveldb files, so opt for high speed NVMe when possible.

@adrian, we also realized the issue, and the team is working on this to figure out how we can reduce the disk IO. But this is a quite low-level problem that may not be done overnight I’m afraid.