Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

env_aws: use best-effort lookup table for CPU performance in EC2 #7828

Merged
merged 4 commits into from
Apr 29, 2020
Merged

env_aws: use best-effort lookup table for CPU performance in EC2 #7828

merged 4 commits into from
Apr 29, 2020

Commits on Apr 29, 2020

  1. env_aws: use best-effort lookup table for CPU performance in EC2 

    Fixes #7681

The current behavior of the CPU fingerprinter in AWS is that it
reads the **current** speed from `/proc/cpuinfo` (`CPU MHz` field).

This is because the max CPU frequency is not available by reading
anything on the EC2 instance itself. Normally on Linux one would
look at e.g. `sys/devices/system/cpu/cpuN/cpufreq/cpuinfo_max_freq`
or perhaps parse the values from the `CPU max MHz` field in
`/proc/cpuinfo`, but those values are not available.

Furthermore, no metadata about the CPU is made available in the
EC2 metadata service.
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-categories.html

Since `go-psutil` cannot determine the max CPU speed it defaults to
the current CPU speed, which could be basically any number between
0 and the true max. This is particularly bad on large, powerful
reserved instances which often idle at ~800 MHz while Nomad does
its fingerprinting (typically IO bound), which Nomad then uses as
the max, which results in severe loss of available resources.

Since the CPU specification is unavailable programmatically (at least
not without sudo) use a best-effort lookup table. This table was
generated by going through every instance type in AWS documentation
and copy-pasting the numbers.
https://aws.amazon.com/ec2/instance-types/

This approach obviously is not ideal as future instance types will
need to be added as they are introduced to AWS. However, using the
table should only be an improvement over the status quo since right
now Nomad miscalculates available CPU resources on all instance types.
    @shoenig
    shoenig committed Apr 29, 2020
    Configuration menu
    Copy the full SHA
    9230fa9 View commit details
    Browse the repository at this point in the history

  2. env_aws: fixup log line 

    Co-Authored-By: Mahmood Ali <mahmood@hashicorp.com>
    @shoenig
    shoenig and Mahmood Ali authored Apr 29, 2020
    Configuration menu
    Copy the full SHA
    f47c57f View commit details
    Browse the repository at this point in the history

  3. env_aws: downgrade log line 

    Co-Authored-By: Mahmood Ali <mahmood@hashicorp.com>
    @shoenig
    shoenig and Mahmood Ali authored Apr 29, 2020
    Configuration menu
    Copy the full SHA
    0d5d178 View commit details
    Browse the repository at this point in the history

  4. env_aws: combine 3 log lines into 1

    @shoenig
    shoenig committed Apr 29, 2020
    Configuration menu
    Copy the full SHA
    a869394 View commit details
    Browse the repository at this point in the history