You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are currently 64 fluffy nodes running on the Portal mainnet, each with storage-capacity of 35GB.
As Portal network is further evolving into production state, we want to increase the amount of nodes our infrastructure runs.
To improve testing we want to have more but smaller nodes. That is, a smaller storage-capacity, e.g. the current default of 2GB, and 128 nodes added.
Lowering the storage-capacity will also automatically lower the CPU, memory and bandwidth requirements.
The reason for this is when a node stores less data, it will also receive less requests for data and less offers for storing data.
Some data from metrics from current fleet:
Memory: The current nodes do not seem to ever go over 200MB RSS per node, in theory this should be even less for a 2GB(storage) node.
CPU: A single node is using 2% to 10% of a core currently, depending on what is going on in the network, in theory this should be even less for a 2GB node.
Bandwidth: I had a look at the network traffic metrics for a single machine (32 nodes). It is between 10 and 20 Mb/s (both in/out). That means for a node of 2GB the traffic should be no more than 6.25 Kb/s on average. It will however be a factor (or 2 factors?) higher at first start-up of the node because the data radius will still be set to the max to fill up the storage-capacity quicker.
Storage capacity I would set at 2GB, perhaps increasing it in the future to 4GB if CPU/Mem/bandwith resource usage allows for that.
The amount of nodes I would like add is 128.
I am open to both using individual droplets for each node or to use several machines as we do now. But each node should have its own IPv4 address. We had some cost calculations done before: #186 (comment)
Individual droplets might be better for more realistic network delays. Although in practice those droplets would probably all end up in the same data-center anyhow?
Aside from storage-capacity the other node settings should remains the same.
The text was updated successfully, but these errors were encountered:
There are currently 64 fluffy nodes running on the Portal mainnet, each with storage-capacity of 35GB.
As Portal network is further evolving into production state, we want to increase the amount of nodes our infrastructure runs.
To improve testing we want to have more but smaller nodes. That is, a smaller storage-capacity, e.g. the current default of 2GB, and 128 nodes added.
Lowering the storage-capacity will also automatically lower the CPU, memory and bandwidth requirements.
The reason for this is when a node stores less data, it will also receive less requests for data and less offers for storing data.
Some data from metrics from current fleet:
Storage capacity I would set at 2GB, perhaps increasing it in the future to 4GB if CPU/Mem/bandwith resource usage allows for that.
The amount of nodes I would like add is 128.
I am open to both using individual droplets for each node or to use several machines as we do now. But each node should have its own IPv4 address. We had some cost calculations done before: #186 (comment)
Individual droplets might be better for more realistic network delays. Although in practice those droplets would probably all end up in the same data-center anyhow?
Aside from storage-capacity the other node settings should remains the same.
The text was updated successfully, but these errors were encountered: