Was this page helpful?
Caution
You're viewing documentation for a previous version of ScyllaDB Enterprise. Switch to the latest stable version.
Scylla runs on 64-bit Linux. Here, you can find which operating systems, distros, and versions are supported.
It’s recommended to have a balanced setup. If there are only 4-8 Logical Cores, large disks or 10Gbps networking may not be needed. This works in the opposite direction as well. Scylla can be used in many types of installation environments.
To see which system would best suit your workload requirements, use the Scylla Sizing Calculator to customize Scylla for your usage.
Scylla tries to maximize the resource usage of all system components. The shard-per-core approach allows linear scale-up with the number of cores. As you have more cores, it makes sense to balance the other resources, from memory to network.
Scylla requires modern Intel CPUs that support the SSE4.2 instruction set and will not boot without it.
The following CPUs are supported by Scylla:
Intel core: Westmere or later (2010)
Intel atom: Goldmont or later (2016)
AMD low power: Jaguar or later (2013)
AMD standard: Bulldozer or later (2011)
In terms of the number of cores, any number will work since Scylla scales up with the number of cores. A practical approach is to use a large number of cores as long as the hardware price remains reasonable. Between 20-60 logical cores (including hyperthreading) is a recommended number. However, any number will fit. When using virtual machines, containers, or the public cloud, remember that each virtual CPU is mapped to a single logical core, or thread. Allow Scylla to run independently without any additional CPU intensive tasks on the same server/cores as Scylla.
The more memory available, the better Scylla performs, as Scylla uses all of the available memory for caching. The wider the rows are in the schema, the more memory will be required. 64 GB-256 GB is the recommended range for a medium to high workload. Memory requirements are calculated based on the number of lcores you are using in your system.
Recommended size: 16 GB or 2GB per lcore (whichever is higher)
Maximum: 1 TiB per lcore, up to 256 lcores
Minimum:
For test environments: 1 GB or 256 MiB per lcore (whichever is higher)
For production environments: 4 GB or 0.5 GB per lcore (whichever is higher)
We highly recommend SSD and local disks. Scylla is built for a large volume of data and large storage per node. You can use up to 100:1 Disk/RAM ratio, with 30:1 Disk/RAM ratio as a good rule of thumb; for example, 30 TB of storage requires 1 TB of RAM. We recommend a RAID-0 setup and a replication factor of 3 within the local datacenter (RF=3) when there are multiple drives.
HDDs are supported but may become a bottleneck. Some workloads may work with HDDs, especially if they play nice and minimize random seeks. An example of an HDD-friendly workload is a write-mostly (98% writes) workload, with minimal random reads. If you use HDDs, try to allocate a separate disk for the commit log (not needed with SSDs).
Scylla is flushing memtables to SSTable data files for persistent storage. SSTables are periodically compacted to improve performance by merging and rewriting data and discarding the old one. Depending on compaction strategy, disk space utilization temporarily increases during compaction. For this reason, you should leave an adequate amount of free disk space available on a node. Use the following table as a guidelines for the minimum disk space requirements based on the compaction strategy:
Compaction Strategy |
Recommended |
Minimum |
|---|---|---|
Size Tiered Compaction Strategy (STCS) |
50% |
70% |
Leveled Compaction Strategy (LCS) |
50% |
80% |
Time-window Compaction Strategy (TWCS) |
50% |
70% |
Incremental Compaction Strategy (ICS) |
70% |
80% |
Use the default ICS (Scylla Enterprise) or STCS (Scylla Open Source) unless you’ll have a clear understanding that another strategy is better for your use case. More on choosing a Compaction Strategy. In order to maintain a high level of service availability, keep 50% to 20% free disk space at all times!
A network speed of 10 Gbps or more is recommended, especially for large nodes. To tune the interrupts and their queues, run the Scylla setup scripts.
Note
Some of the ScyllaDB configuration features rely on querying instance metadata. Disabling access to instance metadata will impact using Ec2 Snitches and tuning performance. See AWS - Configure the instance metadata options for more information.
We highly recommend EC2 I3 instances—High I/O. This family includes the High Storage Instances that provide very fast SSD-backed instance storage optimized for very high random I/O performance and provide high IOPS at a low cost. We recommend using enhanced networking that exposes the physical network cards to the VM.
i3 instances are designed for I/O intensive workloads and equipped with super-efficient NVMe SSD storage. It can deliver up to 3.3 Million IOPS. An i3 instance is great for low latency and high throughput, compared to the i2 instances, the i3 instance provides storage that it’s less expensive and denser along with the ability to deliver substantially more IOPS and more network bandwidth per CPU core.
Model |
vCPU |
Mem (GB) |
Storage (NVMe SSD) |
|---|---|---|---|
i3.xlarge |
4 |
30.5 |
0.950 TB |
i3.2xlarge |
8 |
61 |
1.9 TB |
i3.4xlarge |
16 |
122 |
3.8 TB |
i3.8xlarge |
32 |
244 |
7.6 TB |
i3.16xlarge |
64 |
488 |
15.2 TB |
i3.metal New in version 2.3 |
72 * |
512 |
8 x 1.9 NVMe SSD |
* i3.metal provides 72 logical processors on 36 physical cores
Source: Amazon EC2 I3 Instances
More on using Scylla with i3.metal vs i3.16xlarge
i3en instances have up to 4x the networking bandwidth of i3 instances, enabling up to 100 Gbps of sustained network bandwidth.
i3en support is available for Scylla Enterprise 2019.1.1 and higher and Scylla Open Source 3.1 and higher.
Model |
vCPU |
Mem (GB) |
Storage (NVMe SSD) |
|---|---|---|---|
i3en.large |
2 |
16 |
1 x 1,250 GB |
i3en.xlarge |
4 |
32 |
1 x 2,500 GB |
i3en.2xlarge |
8 |
64 |
2 x 2,500 GB |
i3en.3xlarge |
12 |
96 |
1 x 7,500 GB |
i3en.6xlarge |
24 |
192 |
2 x 7,500 GB |
i3en.12xlarge |
48 |
384 |
4 x 7,500 GB |
i3en.24xlarge |
96 |
768 |
8 x 7,500 GB |
All i3en instances have the following specs:
3.1 GHz all-core turbo Intel® Xeon® Scalable (Skylake) processors
Intel AVX†, Intel AVX2†, Intel AVX-512†, Intel Turbo
EBS Optimized
Enhanced Networking
See Amazon EC2 I3en Instances for details.
i4i support is available for ScyllaDB Open Source 5.0 and later and ScyllaDB Enterprise 2021.1.10 and later.
Model |
vCPU |
Mem (GB) |
Storage (NVMe SSD) |
|---|---|---|---|
i4i.large |
2 |
16 |
1 x 468 GB |
i4i.xlarge |
4 |
32 |
1 x 937 GB |
i4i.2xlarge |
8 |
64 |
1 x 1,875 GB |
i4i.4xlarge |
16 |
128 |
1 x 3,750 GB |
i4i.8xlarge |
32 |
256 |
2 x 3,750 GB |
i4i.16xlarge |
64 |
512 |
4 x 3,750 GB |
i4i.32xlarge |
128 |
1,024 |
8 x 3,750 GB |
i4i.metal |
128 |
1,024 |
8 x 3,750 GB |
All i41 instances have the following specs:
3.5 GHz all-core turbo Intel® Xeon® Scalable (Ice Lake) processors
40 Gbps bandwidth to EBS in the largest size and up to 10 Gbps in the four smallest sizes (twice that of i3 instances. Up to 75 Gbps networking bandwidth (three times more than I3 instances).
AWS Nitro SSD storage
See Amazon EC2 I4i Instances for specification details.
See ScyllaDB on the New AWS EC2 I4i Instances: Twice the Throughput & Lower Latency to learn more about using ScyllaDB with i4i instances.
Pick a zone where Haswell CPUs are found. Local SSD performance offers, according to Google, less than 1 ms of latency and up to 680,000 read IOPS and 360,000 write IOPS. Image with NVMe disk interface is recommended, CentOS 7 for Scylla Enterprise 2020.1 and older, and Ubuntu 20 for 2021.1 and later. (More info)
Recommended instances types are n1-highmem and n2-highmem
Model |
vCPU |
Mem (GB) |
Storage (GB) |
|---|---|---|---|
n1-highmem-2 |
2 |
13 |
375 |
n1-highmem-4 |
4 |
26 |
750 |
n1-highmem-8 |
8 |
52 |
1,500 |
n1-highmem-16 |
16 |
104 |
3,000 |
n1-highmem-32 |
32 |
208 |
6,000 |
n1-highmem-64 |
64 |
416 |
9,000 |
Model |
vCPU |
Mem (GB) |
Storage (GB) |
|---|---|---|---|
n2-highmem-2 |
2 |
16 |
375 |
n2-highmem-4 |
4 |
32 |
750 |
n2-highmem-8 |
8 |
64 |
1500 |
n2-highmem-16 |
16 |
128 |
3,000 |
n2-highmem-32 |
32 |
256 |
6,000 |
n2-highmem-48 |
48 |
384 |
9,000 |
n2-highmem-64 |
64 |
512 |
9,000 |
n2-highmem-80 |
80 |
640 |
9,000 |
Storage: each instance can support maximum of 24 local SSD of 375 GB partitions each for a total of 9 TB per instance
The Lsv2-series features high throughput, low latency, and directly mapped local NVMe storage. The Lsv2 VMs run on the AMD EPYCTM 7551 processor with an all-core boost of 2.55GHz.
Model |
vCPU |
Mem (GB) |
Storage |
|---|---|---|---|
L8s_v2 |
8 |
64 |
1 x 1.92 TB |
L16s_v2 |
16 |
128 |
2 x 1.92 TB |
L32s_v2 |
32 |
256 |
4 x 1.92 TB |
L48s_v2 |
48 |
384 |
6 x 1.92 TB |
L64s_v2 |
64 |
512 |
8 x 1.92 TB |
L80s_v2 |
80 |
640 |
10 x 1.92 TB |
More on Azure Lsv2 instances here
An OCPU is defined as the CPU capacity equivalent of one physical core of an Intel Xeon processor with hyperthreading enabled. For Intel Xeon processors, each OCPU corresponds to two hardware execution threads, known as vCPUs.
Model |
OCPU |
Mem (GB) |
Storage |
|---|---|---|---|
VM.DenseIO2.8 |
8 |
120 |
6.4 TB |
VM.DenseIO2.16 |
16 |
240 |
12.8 TB |
VM.DenseIO2.24 |
24 |
320 |
25.6 TB |
BM.DenseIO2.52 |
52 |
768 |
51.2 TB |
BM.HPC2.36 |
36 |
384 |
6.7 TB |
Was this page helpful?