So what is an f1-micro instance capable of? Let’s find out.
The f1-micro is a shared-core machine type having 0.2 virtual CPUs. A virtual CPU is a single hardware hyperthread on an Intel Xeon E5.
According to the documentation, the f1-micro has a bursting capability that allows it to use additional physical CPU for “short periods” of time “automatically”.
So how exactly does “0.2 CPU” look like? Let’s kick the tyres a bit:
And here is what we saw:
The load average stays at 3, corresponding to the number of tasks run by
stress. The user CPU stayed at 0.22 for the duration of execution. The
guest VM always sees that CPU steal as 0, but as you can see from the graph, the
total CPU ticks available to the VM’s CPU gets throttled down to 0.2 once it
actually starts using it.
In summary – yes, you really get only 0.2 of a CPU.
0.6 GB RAM comes to a total available memory of 588 MiB reported by an Ubuntu 16.04 kernel.
By default, each project in the Google Cloud Platform (GCP) comes with a private network with built-in DHCP and DNS servers. Each VM gets a private IP, and an optional public IPv4 address from a GCP-wide pool of IPs.
Let’s test it out:
Close enough. You can read more about qperf here.
As with AWS, the disk I/O throughput is carved out of the total network bandwidth. It is not documented how the bandwidth is split or traffic is shaped between the two, but of course, it’s best practice not to have both contending.
GCP offers magnetic and SSD block storage, and NVMe-based instance storage. There is no IOPS provisioning for block storage, rather the throughput is computed using guidelines given in this documentation.
According to that, the 30 GB magnetic disk storage in the free tier should have write throughput of:
- write IOPS = 1.5 IOPS/GB * 30 GB = 45 IOPS
- write throughput = 0.12 MB/s/GB * 30 GB = 3.6 MB/s
There is also another limit, imposed by the network throughput cap, and documented here. Basically, if a process tries to write K bytes of data to the disk, the device driver writes out 3.3 * K bytes of data to the network. Because of the network cap, this introduces a limit on the write throughput:
- write throughput = 1 Gbps / 3.3 = ~36 MB/s
Now let’s try a few writes and reads:
Hmm, we actually expected tthe 3.6 MB/s limit imposed by the disk size to be hit, rather than the 36 MB/s limit imposed by the network egress cap. It is not clear why this is so.
Let’s have a look at the graphs:
We hit around 211 IOPS for the write. And here is the disk throughput graph showing reads and writes at ~33 MB/s:
The VM “Failover”
Google Cloud VMs have a built-in “failover” feature, which they call live migration Essentially, a running VM can be migrated from one physical host to another with a downtime in the order of 100s of milliseconds. The migration is automatic, and typically undetectable, but for logs like this in the GCP console:
Much better than those your-instances-will-be-terminated emails, for sure.
OpsDash is a server monitoring, service monitoring, and database monitoring solution for monitoring MySQL, PostgreSQL, MongoDB, memcache, Redis, Apache, Nginx, Elasticsearch and more. It provides intelligent, customizable dashboards and spam-free alerting via email, HipChat, Slack, PagerDuty and Webhooks. Send in your custom metrics with StatsD and Graphite interfaces built into each agent.