🎉 Announcing new lower pricing — up to 40% lower costs for Cloud Servers and Cloud SQL! Read more →

Contents

Resizing a Cloud Server

Cloud Servers can be resized at any time by changing the Server Type – which defines the amounts of RAM, CPU and local SSD storage allocated to the cloud server.

Resizing to a larger type

When increasing the RAM amount, the resize can be initiated while the Cloud Server is running or stopped (i.e state of active or inactive).

From the Cloud Server view, choose Resize from the Server Type details panel:

Choose the new Server Type you wish to resize to and click Save:

Accessing new resources

After a successful Server Type change the increased RAM, CPU and (where relevant) local SSD allocations are made available to the Cloud Server immediately.

However, whether or not the new resource allocations are ready to be used straightaway will depend on the Cloud Server’s OS.

For example, one particular OS may recognise new CPU allocations and bring them online straightaway, whereas another may require restarting or bringing the new CPUs online manually.

RAM

The current memory available within a Cloud Server can be viewed using lsmem:

$ lsmem
RANGE                                 SIZE  STATE REMOVABLE BLOCK
0x0000000000000000-0x000000003fffffff   1G online       yes   0-7
0x0000000100000000-0x000000013fffffff   1G online       yes 32-39

Memory block size:       128M
Total online memory:       2G
Total offline memory:      0B

In the example above, a 1GB Cloud Server has been resized to 2GB. There are two entries in the list and both lines have a STATE of online giving a new total online memory of 2GB.

If, following a resize, additional memory remains offline it can usually be brought online manually by running the following command or restarting:

$ echo 1 | sudo tee /sys/devices/system/memory/memory[0-9]*/online

CPU

The current CPU allocation of a Cloud Server can be viewed using lscpu:

$ lscpu -e
CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE
0    0      0    0 0:0:0:0          yes
1    0      1    1 1:1:1:1          yes
2    0      2    2 2:2:2:2          no
3    0      3    3 3:3:3:3          no

In the example above, the CPU allocation has increased from 2 to 4 and the operating system recognises there are two additional CPUs present but they are not currently online.

If there are additional CPUs made available by the resize but which haven’t automatically been brought online by the operating system, we need to bring them online manually by running the following command or by simply restarting the server:

$ echo 1 | sudo tee /sys/devices/system/cpu/cpu[0-9]*/online
1

Local SSD storage

The current storage available within a Cloud Server can be viewed using lsblk:

$ lsblk /dev/vda
NAME    MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
vda     252:0    0   60G  0 disk
├─vda1  252:1    0 29.9G  0 part /
├─vda14 252:14   0    4M  0 part
└─vda15 252:15   0  106M  0 part /boot/efi

In the example above, the storage has been increased from 30G to 60G. The vda device is now showing as 60GB but the vda1 partition is still ~30GB and needs to be “grown” to use the available space:

$ sudo growpart /dev/vda 1
CHANGED: partition=1 start=227328 old: size=62687199 end=62914527 new: size=125601759 end=125829087

Once the partition has been grown we can expand the filesystem to fill the partition.

Most of our official images use ext4, so we use resize2fs:

$ sudo resize2fs /dev/vda1
resize2fs 1.46.5 (30-Dec-2021)
Filesystem at /dev/vda1 is mounted on /; on-line resizing required
old_desc_blocks = 4, new_desc_blocks = 8
The filesystem on /dev/vda1 is now 15700219 (4k) blocks long.

For xfs formatted root partitions, use xfs_growfs:

$ sudo xfs_growfs /dev/vda1

meta-data=/dev/vda1              isize=512    agcount=16, agsize=655360 blks
        =                       sectsz=512   attr=2, projid32bit=1
        =                       crc=1        finobt=1, sparse=1, rmapbt=0
        =                       reflink=1    bigtime=0 inobtcount=0
data     =                       bsize=4096   blocks=10485760, imaxpct=25
        =                       sunit=16     swidth=16 blks
naming   =version 2              bsize=4096   ascii-ci=0, ftype=1
log      =internal log           bsize=4096   blocks=5120, version=2
        =                       sectsz=512   sunit=16 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
data blocks changed from 10485760 to 26214400

Resizing to a smaller type

When decreasing the RAM amount the Cloud Server must be in inactive state (i.e shut down) before the resize request can be initiated.

Once the Cloud Server is started again the reduced RAM and CPU allocations will be available.

  1. From the Cloud Server view, click the Power State dropdown, choose Shutdown and then click Shutdown again in the confirmation dialog
  2. Wait until the status of the Cloud Server updates to inactive
  3. Now click the Resize button in the Server Type detail
  4. Choose the new smaller Server Type you wish to resize to and click Save
  5. Click Resize in the dialog to confirm the request
  6. From the Cloud Server view, again click the Power State dropdown and choose Start
  7. Once the state changes to active the server will begin booting
  8. Access the server via SSH to confirm the change in resource allocation

Last updated: 21 Sep 2022 at 14:21 UTC

Try Brightbox risk-free with £50 free credit Sign up takes just two minutes...