Choose the best Google cloud instance types for your workloads

Workload resource requirements and standard machine types

Much like sizing physical servers to a particular application, there are three degrees of freedom when selecting a Google cloud virtual instance: CPU, memory and local storage performance. Since requirements for compute and memory are typically correlated, Google, like Amazon Web Services (AWS) and Azure, preconfigures instances with fixed ratios of RAM to virtual CPU (vCPU). However, because some workloads demand more CPU cycles or memory, there are three families of Google cloud instance types:

• Standard machine types -- have 3.75 GB of memory for every vCPU
• High-memory machine types -- have 6.5 GB of memory per vCPU
• High-CPU machine types -- have 0.9 GB of memory per vCPU

Google also offers shared-core machines that share one vCPU with several workloads, but can burst to use additional vCPUs for short periods as system resources are available.

Standard machines are available in 1 to 32 vCPUs in powers of two -- for example, 2, 4, 8, 16 and so on -- while high-memory and high-CPU types start with 2 vCPUs. What Google terms n1 vCPUs are a synthetic standard that corresponds to a single core hyper-thread on a 2.6 GHz Intel Xeon E5 (Sandy Bridge), 2.5 GHz Intel Xeon E5 v2 (Ivy Bridge), 2.3 GHz Intel Xeon E5 v3 (Haswell) or 2.2 GHz Intel Xeon E5 v4 (Broadwell).

The single core performance of a Broadwell E5 is about 20% to 25% higher than that of the first-generation Sandy Bridge, while the frequency ratio used by Google is 1.18:1, so Broadwell vCPUs should be slightly faster for most workloads. However, users can't directly choose CPU implementation when configuring instances, since Google uses different systems in different zones. For example, Google upgraded the Western U.S. zone to the latest v4 Broadwell processors, while the Central U.S. uses a mixture of first-, second- and third-generation CPUs.

Users must understand application requirements before selecting Google cloud instance types. The standard machines will be best for most workloads, while shared, burstable instances are useful for small, lightweight or background applications. Choosing the right mix of vCPUs and memory is problematic without application profiling, but Google offers a recommendation engine, based on Stackdriver, that collects system metrics to generate sizing guidance.

Recommendations are based on the prior eight days of data using the following principles:

• Instances with low CPU utilization most of the time should use fewer vCPUs and those with high utilization should use more vCPUs.
• Instances that don't use a large fraction of available memory should choose a machine with less memory, and those with consistently high memory usage should use a configuration with more memory.

Google custom machines and local storage

Google also supports custom instance types in case one of its standard configurations doesn't fit for a particular workload. Custom instances can be from 1 to 32 vCPUs -- in even numbers -- with a memory ratio between 0.9 and 6.5 GB per vCPU in 0.25 GB increments.

Google cloud instance types also support persistent block storage, using either hard-drive disks (HDDs) or solid-state drives (SSDs). Either type can be up to 64 TB and instances can assign 16 disks with a single core up to 128 disks with 8 or more cores. Disk performance scales with size, but SSDs provide about eight times more read, 67% more write IOPS and between 50% and 100% more read and write throughput per instance than HDDs.

In general, transactional workloads with many small reads and writes will benefit from SSDs, while applications like content delivery and rich media software should stick with HDDs. Google automatically manages persistent storage, but also supports locally attached, user-managed iSCSI or NVMe SSDs that provide even more performance.

Recommendations

With a variety of standard Google cloud instance types, and the ability to customize CPU, memory and local storage, users have a lot of options. In general, stick with one of the preconfigured instance types and use Google's automated recommendations to tweak sizing. Think twice about using custom machine types until you have production experience and performance data that shows the need for a non-standard CPU-memory combination.

Although custom machines can save money if you need a configuration between two of the predefined types, Google bills for them hourly, based on the number of vCPUs and memory hours used, rather than in one-minute increments like it does for standard types.