Notes
  • Blockchain
  • About this repository
  • References
  • Carret Position
  • Loggia and Balcony
  • automobile
    • Motorbike
  • computer
    • Kubernetes Event-driven Autoscaling (KEDA)
    • Protobuf
    • [[Amazon]] [[Identity and Access Management]] ([[IAM]])
    • Apdex
    • Architecture Decision Record
    • Audio
    • [[Amazon Web Services]] (AWS) Lambda
    • Blockchain
    • C/C++
    • Cache line
    • Caching strategies
    • Database
    • Design Patterns
    • Docker compose
    • Event Driven Design
    • False sharing
    • Git
    • [[Go]] common mistakes
    • [Go] [[subtests]]
    • Go
    • Janus
    • Jest
    • Kubernetes
    • Log-Structured Merge-tree
    • Media server
    • MySQL: Charset, Collation and UCA
    • Netflix
    • Opus Codec
    • Process, Thread
    • ReDoS - [[Regular expression]] Denial of Service
    • Rust
    • ScyllaDB
    • Shell Functions
    • Signals (The GNU Library)
    • Solidity
    • Sources
    • SQL
    • Transmission Control Protocol (TCP)
    • Ten design principles for Azure applications
    • Transient Fault Handling
    • twemproxy
    • Video
    • Web2 vs Web3
    • WebRTC
    • Microservice architecture
      • 3rd party registration
      • Command Query Responsibility Segregation (CQRS)
      • Access token
      • Aggregate
      • API Composition
      • API gateway/Backends for Frontends
      • Application metrics
      • Audit logging
      • Circuit Breaker
      • Client-side discovery
      • Client-side UI composition
      • Consumer-driven contract test
      • Consumer-side contract test
      • Database per Service
      • Decompose by business capability
      • Decompose by subdomain
      • Distributed tracing
      • Domain event
      • Domain-specific
      • Event sourcing
      • Exception tracking
      • Externalized configuration
      • Health check API
      • Log aggregation
      • Log deployments and changes
      • Messaging
      • Microservice architecture
      • Microservice Chassis
      • Multiple Service instances per host
      • Polling publisher
      • Remote Procedure invocation
      • Saga
      • Self-contained service
      • Self registration
      • Server-side discovery
      • Server-side page fragment composition
      • Serverless deployment
      • Service Component test
      • Service deployment platform
      • Service instance per Container
      • Service instance per VM
      • Service mesh
      • Service per team
      • Service registry
      • Service template
      • Shared database
      • Single Service instance per host
      • Transaction log tailling
      • Transactional outbox
  • food-and-beverage
    • Cheese
    • Flour
    • Japanese Plum liqueur or Umeshu
    • Sugar
  • management
    • Software Engineering processes
  • medic
    • Desease, disorder, condition, syndrome
    • Motion Sickess
  • others
    • Elliðaey
    • ASCII art
    • Empirical rule
    • Hindsight bias
    • Outcome bias
    • Tam giác Reuleaux
    • Luật Việt Nam
  • soft-skills
    • Emotional intelligence
Powered by GitBook
On this page
  • Getting started
  • System requirements
  • OS Support by Platform and Version
  • Scylla in a Shared Environment
  • Scylla configuration
  1. computer

ScyllaDB

PreviousRustNextShell Functions

Last updated 2 years ago

ScyllaDB uses [[CQL]] ([[Apache]] [[Cassandra]] Query Language)

Getting started

Memory requirements

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 logical cores (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)

Disk requirements

We highly recommend [[SSD]] and local disks. Scylla is built for a large volume of data and large storage per node. The rule of thumb is using 30:1 Disk/RAM ratio; for example, 30 TB of storage requires 1 TB of RAM. When there are multiple drives, we recommend a RAID-0 setup and a replication factor of 3 within the local datacenter (RF=3).

Network requirements

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.

Scylla requires a fix to the XFS append introduced in kernel 3.15 (back-ported to 3.10 in RHEL/CentOS). Scylla will not run with earlier kernel versions

Memory

The most critical resource that Scylla consumes is memory. By default, when Scylla starts up, it inspects the node's hardware configuration and claims all memory to itself, leaving some reserve for the operating system (OS). This is in contrast to most open-source databases that leave most memory for the OS, but is similar to most commercial databases.

In a shared environment, particularly on a desktop or laptop, gobbling up all the machine's memory can reduce the user experience, so Scylla allows reducing its memory usage to a given quantity.

On Ubuntu, open a terminal and edit /etc/default/scylla-server, and add --memory 2G to restrict Scylla to 2 gigabytes of RAM.

On Red Hat / CentOS, open a terminal and edit /etc/sysconfig/scylla-server, and add --memory 2G to restrict Scylla to 2 gigabytes of RAM.

If starting Scylla from the command line, simply append --memory 2G to your command line.

CPU

By default, Scylla will utilize all of your processors (in some configurations, particularly on Amazon AWS, it may leave a core for the operating system)

Scylla offers two options to restrict its CPU utilization:

  • --smp N restricts Scylla to N logical cores; for example with --smp 2 Scylla will not utilize more than two logical cores

  • --overprovisioned tells Scylla that the machine it is running on is used by other processes; so Scylla will not pin its threads or memory, and will reduce the amount of polling it does to a minimum.

On Ubuntu edit /etc/default/scylla-server, and add --smp 2 --overprovisioned to restrict Scylla to 2 logical cores.

On Red Hat / CentOS edit /etc/sysconfig/scylla-server, and add --smp 2 --overprovisioned to restrict Scylla to 2 logical cores.

If starting Scylla from the command line, simply append --smp 2 --overprovisioned to your command line.

Scylla configuration

Installed location
Description

/etc/default/scylla-server (Ubuntu/Debian) /etc/sysconfig/scylla-server (others)

Server startup options

/etc/scylla/scylla.yaml

Main Scylla configuration file

/etc/scylla/cassandra-rackdc.properties

Rack & dc configuration file

Best practices
System requirements
OS Support by Platform and Version
Scylla in a Shared Environment