IBM Cloud Docs
Scaling disk, memory, and CPU

Scaling disk, memory, and CPU

For new hosting models, scaling is available through the CLI, API, and Terraform.

To scale an Isolated Compute host flavor instance, set the relevant hostflavor parameter to the Isolated Compute size you're targeting, such as "b3c.4x16.encrypted". As this includes CPU and RAM allocation selections, do not separately select CPU and RAM.

To scale a Shared Compute host flavor instance between the minimum CPU value and 2 CPU, set the CPU to 0 and scale the RAM allocation using the following commands in this documentation. The CPU value will scale as a ratio of 1 CPU : 8 GB RAM, up to 2 CPU. To scale above 2 CPU, set the CPU and RAM allocations to your target allocation. For both, make sure to include the relevant hostflavor parameter of "multitenant".

To scale an Isolated Compute host flavor instance, set the relevant host_flavor parameter to the Isolated Compute size you're targeting, such as "b3c.4x16.encrypted". As this includes CPU and RAM allocation selections, do not separately select CPU and RAM.

To scale a Shared Compute host flavor instance between the minimum CPU value and 2 CPU, set the CPU to 0 and scale the RAM allocation using the following commands. The CPU value will scale as a ratio of 1 CPU : 8 GB RAM, up to 2 CPU. To scale above 2 CPU, set the CPU and RAM allocations to your target allocation. For both, make sure to include the relevant host_flavor parameter of "multitenant".

To scale an Isolated Compute host flavor instance, set the relevant host_flavor parameter to the Isolated Compute size you're targeting, such as "b3c.4x16.encrypted". As this includes CPU and RAM allocation selections, do not separately select CPU and RAM.

To scale a Shared Compute host flavor instance between the minimum CPU value and 2 CPU, set the CPU to 0 and scale the RAM allocation using the following commands. The CPU value will scale as a ratio of 1 CPU : 8 GB RAM, up to 2 CPU. To scale above 2 CPU, set the CPU and RAM allocations to your target allocation. For both, make sure to include the relevant host_flavor parameter of "multitenant".

You can manually adjust the amount of resources available to your IBM Cloud® Messages for RabbitMQ deployment to suit your workload and the size of your data.

Resource breakdown

Messages for RabbitMQ deployments have three data members in a cluster, and resources are allocated to all three members equally. For example, the minimum storage of a RabbitMQ deployment is 3072 MB, which equates to an initial size of 1024 MB per member. The minimum RAM for a RabbitMQ deployment is 3072 MB, which equates to an initial allocation of 1024 MB per member.

Billing is based on the total amount of resources that are allocated to the service.

Disk usage

Storage shows the amount of disk space that is allocated to your service. Each member gets an equal share of the allocated space. Your data is replicated across three data members in the RabbitMQ cluster, so the total amount of storage you use is approximately three times the size of your data set.

Disk allocation affects the performance of the disk, with larger disks having higher performance. Baseline input/output operations per second (IOPS) performance for disk is 10 IOPS for each GB. Reaching IOPS limits consistently causes throughput and message processing delays, which can be alleviated by scaling up disk space.

You cannot scale down storage. If your data set size has decreased, you can recover space by backing up and restoring to a new deployment.

RAM

RabbitMQ throttles publishing when it detects it is using 40% of available memory to keep memory usage from growing uncontrollably during spike of activity. If you find that you regularly reach the limit, you can allocate more memory to your deployment. Adding memory to the total allocation adds memory to the members equally.

Queue rebalancing

If you notice that one RabbitMQ node is occupying significantly more resources than another, it is likely that the queues are not evenly distributed between the nodes. This can happen for the following possible reasons:

  • You are connected to only one of the VIPs and all the queues are created on a single node.
  • There was a rolling restart, which moves the queues to the node that was restarted first.

Triggering even distribution of queues causes load until all queues are evenly distributed so this action should not be performed while the deployment is under pressure or outscaled.

To evenly distribute the queues, you can use the RabbitMQ management API to run an https POST call /api/rebalance/queues against your deployment.

vCPU

If you find that your database workloads need more CPU resources, you can scale the amount of CPU allocated to your service. If your database instance is on an Isolated Compute hosting model, select the CPU x RAM configuration that matches your resource needs. If your database instance is on a Shared Compute or Dedicated Core hosting model, select the CPU allocation that you want for your database.

Old style dedicated core instances are deprecated, and will be removed in May 2025. For more information on the new hosting models, see the Hosting models overview.

Scaling considerations

  • Scaling your deployment up might cause your RabbitMQ to restart. If your scaled deployment needs to be moved to a host with more capacity, then the databases are restarted as part of the move.

  • Scaling down RAM or CPU does not trigger restarts.

  • Disk cannot be scaled down.

  • Scaling between hosting models (Shared Compute, Isolated Compute, and Dedicated Cores) moves your deployment to new hosts. Your databases are restarted as part of that move. As your deployment is moved to a new host, this can also take longer than just adding more resources. For more information, see Shared Compute and Isolated Compute.

  • Similarly, drastically increasing RAM or disk can take longer than smaller increases to account for provisioning more underlying hardware resources.

  • Scaling operations are logged in IBM Cloud® Activity Tracker.

  • If you find consistent trends in resource usage or would like to set up scaling when certain resource thresholds are reached, see Autoscaling.

Scaling via the UI

A visual representation of your data members and their resource allocation is available on the Resources tab of your deployment's Manage page.

The Scale Resources Panel in Resources{: caption="The Scale Resources Panel in Resources" caption-side="bottom"}

Adjust the slider to increase or decrease the resources that are allocated to your service. The slider controls how much memory or disk is allocated per member. The UI currently uses a coarser-grained resolution of 8 GB increments for disk and 1 GB increments for memory. The UI shows the total allocated memory or disk for the position of the slider. Click Scale to trigger the scaling operations and return to the dashboard overview.

Review current resources and hosting model

IBM Cloud CLI cloud databases plug-in supports viewing and scaling the resources on your deployment. Use the command cdb deployment-groups to see current resource information for your service, including which resource groups are adjustable. To scale any of the available resource groups, use cdb deployment-groups-set command.

For example, with the following command you can view the resource groups for a deployment named "example-deployment". Note that this command will also reveal if your database is a Shared Compute or Isolated Compute instance through the hostflavor attribute. If the hostflavor is null, it is on an old style hosting model.

ibmcloud cdb deployment-groups example-deployment

This command produces the following output:

Group   member
Count   3
|
+   Memory
|   Allocation              3072mb
|   Allocation per member   1024mb
|   Minimum                 3072mb
|   Step Size               384mb
|   Adjustable              true
|
+   CPU
|   Allocation              0
|   Allocation per member   0
|   Minimum                 9
|   Step Size               3
|   Adjustable              true
|
+   Disk
|   Allocation              3072mb
|   Allocation per member   1024mb
|   Minimum                 3072mb
|   Step Size               3072mb
|   Adjustable              true

The deployment has three members, with 3072 MB of RAM disk allocated in total. The "per member" allocation is 1024 MB of RAM and 1024 MB of disk. The minimum value is the lowest the total allocation can be set. The step size is the smallest amount by which the total allocation can be adjusted.

Resources and scaling in the CLI

The cdb deployment-groups-set command allows either the total RAM or total disk allocation to be set in MB. For example, to scale the memory of the "example-deployment" to 4096 MB of RAM for each memory member (for a total memory of 12288 MB), you use the following command:

ibmcloud cdb deployment-groups-set example-deployment member --memory 12288

Determine the hosting model of your database

Use the following command to review the value of the hostflavor attribute. This will be null if the database is on a deprecated hosting model (not Shared or Isolated Compute).

ibmcloud cdb groups <deployment_id> --json

Switching to and between hosting models in the CLI

If your database is a Shared Compute instance, you can adjust the memory, CPU, and disk options with the following command. If your database is not on Shared Compute, this command will also move a database from a different hosting model to the Shared Compute hosting model.

ibmcloud cdb deployment-groups-set <deploymentid> <groupid> [--memory <val>] [--cpu <val>] [--disk <val>] [--hostflavor multitenant]

For example, use the following to scale to a Shared Compute instance or scale up your Shared Compute instance:

ibmcloud cdb deployment-groups-set crn:abc ... xyz:: member  --memory 24576 --cpu 6  --hostflavor multitenant

If your database is an Isolated Compute instance, memory and CPU are adjusted together by selecting the Isolated Compute size (see all sizes in Table 1). Disk is scaled separately. If your database is not on Isolated Compute, this command will also move a database from a different hosting model to the Isolated Compute hosting model.

Note that since the host flavor selection includes CPU and RAM sizes (b3c.4x16.encrypted is 4 CPU and 16 RAM), this request does not accept both an Isolated size selection and separate CPU and RAM allocation selections.

ibmcloud cdb deployment-groups-set <deploymentid> <groupid> [--disk <val>] [--hostflavor <hostflavor>]

For example, use the following to scale to an Isolated Compute instance or scale up your Isolated Compute instance:

ibmcloud cdb deployment-groups-set crn:abc ... xyz:: member  --hostflavor b3c.8x32.encrypted

The hostflavor parameter

The hostflavor parameter defines your compute sizing. To provision a Shared Compute instance, specify multitenant. To provision an Isolated Compute instance, input the appropriate value for your desired CPU and RAM configuration.

Host flavor sizing parameter
Host flavor hostflavor value
Shared Compute multitenant
4 CPU x 16 RAM b3c.4x16.encrypted
8 CPU x 32 RAM b3c.8x32.encrypted
8 CPU x 64 RAM m3c.8x64.encrypted
16 CPU x 64 RAM b3c.16x64.encrypted
32 CPU x 128 RAM b3c.32x128.encrypted
30 CPU x 240 RAM m3c.30x240.encrypted

Review current resources and hosting model

The Foundation Endpoint that is shown on the Overview panel of your service provides the base URL to access this deployment through the API. Use it with the /groups endpoint if you need to manage or automate scaling programmatically.

To view the current and scalable resources on a deployment, use the /deployments/{id}/groups endpoint. Note that this command will also reveal if your database is a Shared Compute or Isolated Compute instance through the host_flavor attribute. If the host_flavor is null, it is on an old style hosting model.

curl -X GET -H "Authorization: Bearer $APIKEY" 'https://api.{region}.databases.cloud.ibm.com/v5/ibm/deployments/{id}/groups'

Scaling with the API

To scale the memory of a deployment to 4096 MB of RAM for each memory member (for a total memory of 12288 MB), use the following command:

curl -X PATCH 'https://api.{region}.databases.cloud.ibm.com/v5/ibm/deployments/{id}/groups/member' \
-H "Authorization: Bearer $APIKEY" \
-H "Content-Type: application/json" \
-d '{"memory": {
        "allocation_mb": 12288
      }
    }'

For more information, see the API reference.

Determine the hosting model of your database

Use the following command to review the value of the host_flavor attribute. This value will be null if the database is on a deprecated hosting model (not Shared or Isolated Compute).

curl -X GET https://api.{region}.databases.cloud.ibm.com/v5/ibm/deployments/{id}/groups 
-H 'Authorization: Bearer <>' \

Switching to and between hosting models in the API

To scale any Cloud Databases Shared Compute instance, use the the following command, setting host_flavor to multitenant. If your database is not on Shared Compute, this command will also move a database from a different hosting model to the Shared Compute hosting model.

curl -X PATCH https://api.{region}.databases.cloud.ibm.com/v5/ibm/deployments/{id}/groups/member
-H 'Authorization: Bearer <>'
-H 'Content-Type: application/json'
-d '{"host_flavor": {"id": "multitenant"},
     "cpu": {"allocation_count": 2},
     "memory": {"allocation_mb": 12288}
    }' \

To scale any instance into a Cloud Databases Isolated Compute instance or to scale to a different Isolated Compute size, use the host_flavor parameter, this time set to the desired Isolated Compute size. Available hosting sizes and their host_flavor value parameters are listed in Table 1. For example, {"host_flavor": "b3c.4x16.encrypted"}. Note that since the host flavor selection includes CPU and RAM sizes (b3c.4x16.encrypted is 4 CPU and 16 RAM), this request does not accept both, an Isolated size selection and separate CPU and RAM allocation selections. Scale with the Cloud Databases API Scaling endpoint, with a command like:

curl -X PATCH https://api.{region}.databases.cloud.ibm.com/v5/ibm/deployments/{id}/groups/member
-H 'Authorization: Bearer <>'
-H 'Content-Type: application/json'
-d '{"host_flavor": {"id": "b3c.4x16.encrypted"}}' \

CPU and RAM allocation is not allowed when provisioning or scaling through Isolated Compute. Specify mulitenant for the host_flavor parameter to have independent CPU and RAM selections.

CPU and RAM autoscaling is not supported on Cloud Databases Isolated Compute. Disk autoscaling is available. If you have provisioned an Isolated instance or switched over from a deployment with autoscaling, keep an eye on your resources using IBM Cloud® Monitoring integration, which provides metrics for memory, disk space, and disk I/O utilization. To add resources to your instance, manually scale your deployment.

The host flavor parameter

The host_flavor parameter defines your compute sizing. To provision a Shared Compute instance, specify multitenant. To provision an Isolated Compute instance, input the appropriate value for your desired CPU and RAM configuration.

Table 1 Host flavor sizing parameter
Host flavor host_flavor value
Shared Compute multitenant
4 CPU x 16 RAM b3c.4x16.encrypted
8 CPU x 32 RAM b3c.8x32.encrypted
8 CPU x 64 RAM m3c.8x64.encrypted
16 CPU x 64 RAM b3c.16x64.encrypted
32 CPU x 128 RAM b3c.32x128.encrypted
30 CPU x 240 RAM m3c.30x240.encrypted

Review current resources and hosting model

Review resource allocations to your database by checking your terraform scripts for cpu { allocation_count = }, memory {allocation_mb = }, and disk { allocation_mb = }. Review the host_flavor setting to determine if your database is a Shared Compute or Isolated Compute style hosting model. If host_flavor does not exist, your database is on an old style hosting model.

Scaling with Terraform

Before executing a Terraform script on an existing instance, use the terraform plan command to compare the current infrastructure state with the desired state defined in your Terraform files. Any alteration to the resource_group_id, service plan, version, key_protect_instance, key_protect_key, backup_encryption_key_crn attributes recreates your instance. For a list of current argument references with the Forces new resource specification, see the ibm_database Terraform Registry.

Scale your instance by adjusting your Terraform script for the resource you're interested in. In the following example, cpu, memory, and disk allocations are specified. Note that if you have a host flavor selected (Isolated Compute or Shared Compute Multitenant), keep the host flavor selection in your script.

To implement your change, run terraform apply.

data "ibm_resource_group" "group" {
  name = "<your_group>"
}
resource "ibm_database" "<your_database>" {
  name              = "<your_database_name>"
  plan              = "standard"
  location          = "eu-gb"
  service           = "databases-for-rabbitmq"
  resource_group_id = data.ibm_resource_group.group.id
  tags              = ["tag1", "tag2"]
  adminpassword     = "password12"
  group {
    group_id = "member"
    cpu {
      allocation_count = 6
    }
    memory {
      allocation_mb = 24576
    }
    disk {
      allocation_mb = 256000
    }
  }
  users {
    name     = "user123"
    password = "password12"
  }
  allowlist {
    address     = "172.168.1.1/32"
    description = "desc"
  }
}
output "ICD RabbitMQ database connection string" {
  value = "http://${ibm_database.test_acc.ibm_database_connection.icd_conn}"
}

Switching to and scaling hosting models in Terraform

Select the hosting model you want your database to be scaled to. You can change this later.

To scale your Messages for RabbitMQ instance to the Shared Compute hosting flavor, set the "host_flavor" parameter to multitenant. This works if you want to scale to the Shared Compute hosting flavor, or if you want to keep the host flavor and scale your resources. To implement your change, run terraform apply.

See the following example:

data "ibm_resource_group" "group" {
  name = "<your_group>"
}
resource "ibm_database" "<your_database>" {
  name              = "<your_database_name>"
  plan              = "standard"
  location          = "eu-gb"
  service           = "databases-for-rabbitmq"
  resource_group_id = data.ibm_resource_group.group.id
  tags              = ["tag1", "tag2"]
  adminpassword     = "password12"
  group {
    group_id = "member"
    host_flavor {
      id = "multitenant"
    },
    cpu {
      allocation_count = 6
    }
    memory {
      allocation_mb = 24576
    }
    disk {
      allocation_mb = 256000
    }
  }
  users {
    name     = "user123"
    password = "password12"
  }
  allowlist {
    address     = "172.168.1.1/32"
    description = "desc"
  }
}
output "ICD RabbitMQ database connection string" {
  value = "http://${ibm_database.test_acc.ibm_database_connection.icd_conn}"
}

Scale your Messages for RabbitMQ instance to Isolated Compute with the same "host_flavor" parameter, set to the desired Isolated size. This command works to scale your database instance to a different Isolated Compute size, as well as to move from another host flavor to the Isolated Compute host flavor. Available hosting sizes and their host_flavor value parameters are listed in Table 1. For example, {"host_flavor": "b3c.4x16.encrypted"}. Note that since the host flavor selection includes CPU and RAM sizes (b3c.4x16.encrypted is 4 CPU and 16 RAM), this request does not accept both an Isolated size selection and separate CPU and RAM allocation selections.

To implement your change, run terraform apply.

data "ibm_resource_group" "group" {
  name = "<your_group>"
}
resource "ibm_database" "<your_database>" {
  name              = "<your_database_name>"
  plan              = "standard"
  location          = "eu-gb"
  service           = "databases-for-rabbitmq"
  resource_group_id = data.ibm_resource_group.group.id
  tags              = ["tag1", "tag2"]
  adminpassword     = "password12"
  group {
    group_id = "member"
    host_flavor {
      id = "b3c.8x32.encrypted"
    }
    disk {
      allocation_mb = 256000
    }
  }
  users {
    name     = "user123"
    password = "password12"
  }
  allowlist {
    address     = "172.168.1.1/32"
    description = "desc"
  }
}
output "ICD RabbitMQ database connection string" {
  value = "http://${ibm_database.test_acc.ibm_database_connection.icd_conn}"
}