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
Scylla Manager 3.4 will include a set of improvements for the restore process conducted with SM.
We identified a few bottlenecks in pre-3.4 versions of the manager that prevented full utilization of cluster nodes during the restore procedure.
For example:
Tables were being restored sequentially, meaning only the SSTables of a given table were distributed to the cluster nodes. The batch-size flag for the restore task defines the number of files sent to each node. If the batch size is too large, some nodes may not receive any batches (due to an insufficient number of SSTables for a single table), causing them to remain idle.
The default batch-size value of 2 led to suboptimal utilization of Scylla's load and stream feature across shards. We found that a utilization level of ~80% could be reached by fine-tuning this value. A higher batch-size indicates that tables cannot be restored sequentially if we aim to utilize all nodes during the restore process.
The default value for the number of transfers (2) resulted in the data download not fully utilizing available bandwidth. ...
We must create documentation detailing the implementation specifics of the restore procedure in Manager 3.4.
The text was updated successfully, but these errors were encountered:
Scylla Manager 3.4 will include a set of improvements for the restore process conducted with SM.
We identified a few bottlenecks in pre-3.4 versions of the manager that prevented full utilization of cluster nodes during the restore procedure.
For example:
We must create documentation detailing the implementation specifics of the restore procedure in Manager 3.4.
The text was updated successfully, but these errors were encountered: