N4A VMs powered by GoogleAxion processors,N4D VMs powered by 5thgeneration AMD EPYC Turin processors, andN4 VMs powered by 5thgeneration Intel Xeon processors useTitanium. These machine series also use next generation dynamicresource management to drive cost efficiency by making better use of thephysical resources available on host machines, and also uses a custom-built CPUscheduler and performance-aware live migration to balance workload performance needswith available resources. These are the same technologies thatGoogle Search, Google Ads, Google Maps, and YouTubeservices use to run their latency-sensitive workloads efficiently.

Next generation dynamic resource management also has better NUMA affinity,more accurate prediction of resource requirements, and faster rebalancing usingperformance-aware live migration.

How dynamic resource management works

Virtual CPUs (vCPUs) are implemented as threads that are scheduledto run on demand like any other thread on a host. When the vCPU has work to do,the work is assigned to an available physical CPU on which to run until itgoes to sleep again. Similarly, virtual RAM is mapped to physical host pagesusing page tables that are populated when a guest-physical page is first accessed.This mapping remains fixed until the VM indicates that a guest-physical page isno longer needed.

Dynamic resource management enables Compute Engine to better usethe available physical CPUs by scheduling VMs to servers based on resourcedemand, and scheduling vCPU threads to physical CPUs such that wait time isminimized. In most cases, we can do this seamlessly, so Google Cloud canrun VMs more efficiently on fewer servers.

Components of dynamic resource management

Compute Engine uses the following technologies for dynamic resourcemanagement:

Larger, more efficient physical servers

Core count and RAM density have steadily increased such that now the hostservers have far more resources than any individual VM. Google continuallybenchmarks new hardware and looks for platforms that are cost-effective andperform well for the widest variety of cloud workloads and services, allowingyou to take advantage of the newest technologies when they're available.

Intelligent VM placement

Google's cluster management system observes the CPU, RAM, andother resource demands of VMs running on a physical server. It uses thisinformation to predict how a newly added VM will perform on that server. It thensearches across thousands of servers to find the best location to add a VM.These observations ensure that when a new VM is placed, it is compatible withits neighbors and unlikely to experience interference from those instances.

Performance-aware live migration

After VMs are placed on a host, Compute Engine continuously monitorsVM performance and wait times. If the resource demands of the VMs increase,Compute Engine can uselive migrationto transparently shift workloads to other hosts in the data center.The live migration policy is guided by a predictive approach that givesCompute Engine time to shift the load, often before any wait time isexperienced by the VMs.

Hypervisor CPU scheduler

The hypervisor CPU scheduler dynamically maps virtual CPU and memoryto the physical CPU and memory of the host server on demand. This dynamicmanagement drives cost efficiency in VMs by making better use of thephysical resources. Efficient use of resources means Compute Enginecan run VMs more efficiently on fewer servers, allowing Google Cloud to pass onsavings to users.

First generation dynamic resource management

E2 was the first VM series to offer dynamic resource management using a virtio memory balloon device.

Virtio memory balloon device with E2 VMs

Memory ballooning is an interface mechanism between host and guest todynamically adjust the size of the reserved memory for the guest. E2 uses avirtio memory balloon device to implement memory ballooning. Through the virtio memory balloondevice, a host can explicitly ask a guest to yield a certain amount of freememory pages (also called memory balloon inflation), and reclaim the memory sothat the host can use the free memory for other VMs. Likewise, the virtio memoryballoon device can return memory pages back to the guest by deflating thememory balloon. E2 VMs are the only machine family that uses the memoryballoon device.

Compute Engine E2 VM instances that are based on apublic image have avirtio memory balloon device,which monitors the guest operating system's memory use. The guestoperating system communicates its available memory to the host system. The hostreallocates any unused memory to other processes on demand, thereby using memorymore effectively. Compute Engine collects and uses this datato make more accuraterightsizing recommendations.

Verifying the driver installation

To check if your image has the virtio memory balloon device driver installed andloaded, run the following command.

sudo modinfo virtio_balloon > /dev/null && echo Balloon driver is \installed || echo Balloon driver is not installed; sudo lsmod | grep \virtio_balloon > /dev/null && echo Balloon driver is loaded || echo \Balloon driver is not loaded

sudo /sbin/sysctl -w vm.overcommit_memory=1

vm.overcommit_memory=1

googet verify google-compute-engine-driver-balloon

Disabling the virtio memory balloon device

Using the virtio memory balloon device enables Compute Engine toutilize memory resources more effectively so Google Cloud can offer E2 VMs atlower prices. You can opt out of the virtio memory balloon device by disablingthe device driver. After disabling the virtio memory balloon device, you willcontinue to receiverightsizing recommendations;however, they might not be as accurate.

sudo rmmod virtio_balloon

googet -noconfirm remove google-compute-engine-driver-balloon

What's next

• Read the blog aboutDynamic resource management.
• Review theN4D machine series information.
• Review theN4 machine series information.
• Review theN4A machine series information.
• Review theE2 machine series information.
• Create a VM.