Operational guidelines

  • ARM-based CPU
  • 1:8 ratio of vCPU to GiB memory
  • 1:16 ratio of vCPU to GiB local instance storage (if enabling spill-to-disk)

When operating in AWS, we recommend the following instances:

EC2 Instances
r8g, r7g, and r6g families when running without local disk.
r7gd and r6gd families (and r8gd once available) when running with local disk. Recommended for production.

Starting in v0.3.1, the Materialize on AWS Terraform uses ["r7gd.2xlarge"] as the default node_group_instance_types.

CPU affinity

It is strongly recommended to enable the Kubernetes static CPU management policy. This ensures that each worker thread of Materialize is given exclusively access to a vCPU. Our benchmarks have shown this to substantially improve the performance of compute-bound workloads.

TLS

When running with TLS in production, run with certificates from an official Certificate Authority (CA) rather than self-signed certificates.

Locally-attached NVMe storage

For optimal performance, Materialize requires fast, locally-attached NVMe storage. Having a locally-attached storage allows Materialize to spill to disk when operating on datasets larger than main memory as well as allows for a more graceful degradation rather than OOMing. Network-attached storage (like EBS volumes) can significantly degrade performance and is not supported.

Additional documentation to come

Starting in v0.3.1 of Materialize on AWS Terraform, you can enable disk support for Materialize using OpenEBS and NVMe instance storage. With this change, the following configuration options are available:

When enabled, the Terraform:

  • Installs OpenEBS via Helm;

  • Configures NVMe instance store volumes using a bootstrap script;

  • Creates appropriate storage classes for Materialize.

By default, enable_disk_support is set to true. In addition, the default node_group_instance_types has changed from "r8g.2xlarge" to "r7gd.2xlarge". See Recommended instance types.

See also

Back to top ↑