Analyze clock source differences with Nitro System and AWS System Manager to boost the performance of Amazon EC2 non-Nitro Xen-based nodes
Suresh Bandaru
Master's Program in Telecommunication Systems with an Emphasis on Science at Blekinge Institute of Technology (BTH)
This article delves into the crucial role of clock sources in Linux and their impact on EC2 application performance. It also highlights how AWS's Nitro system capabilities, a game-changer in the field, improve clock timing and offload hypervisor-related tasks, thereby significantly enhancing EC2 performance.?
Our test's purpose was to evaluate the impact of different clock sources on two Amazon Linux EC2 instances. One instance was Nitro-based, and the other was non-Nitro Xen-based. We used SSM documents to change clock timings and observed the resulting differences in performance.?
To conduct the test, we can download the time_test.yaml?(https://static.us-east-1.prod.workshops.aws/public/1231ab2e-8a0c-4139-a2de-057d0c6ec1a9/static/2_Review/Clock_Source_Performance/Code/time_test.yaml) CloudFormation template and select the parameters.
When creating infrastructure, AWS CloudFormation uses a YAML template. The template has sections similar to those shown in time_test.yaml.? Here's an example of a YAML-formatted template fragment.
The "Resources" section is mandatory and must be included in an AWS CloudFormation YAML template's anatomy.
The "time_test.yaml" AWS CloudFormation template manages and organizes cloud resources and settings for creating and running a system. It breaks down the system into different parts, making it easier to manage.
Here are some of the key sections in the template:
AWS CloudFormation's "Format Version" section (optional) identifies the template's capabilities. The latest template format version is 2010-09-09 and is the only valid value. Remember to use a literal string to specify the template format version; you cannot use a parameter or function. AWS CloudFormation assumes the latest template format version if you don't specify a value. Here's an example:
The "Description" section in a template allows you to add comments. Use a literal string of 0-1024 bytes as the "description declaration" value.?No parameters or functions can be used. Here's an example:
The AWS CloudFormation template includes a " parameters " section allowing users to customize the CloudFormation stack. By default, the XenNodeInstanceType is set to m4.large, which offers a balanced combination of computing power, memory, and network resources. And the Kvm node instance type defaults to m5.large. This instance type provides superior computing power, storage, and network resources thanks to its Intel Xeon processors, up to 25 Gbps network bandwidth, and AWS Nitro System support.
To get the latest Amazon Machine Image (AMI) for a specific region where a stack is being deployed in a CloudFormation template, we can use the LatestAmiId function. This function is easy to use because it defaults to the Amazon Linux AMI. We don't need to specify an AMI ID, so it saves time and effort when deploying stacks in different regions.?
AWS Systems Manager provides public parameters that help you access public AMIs maintained by AWS.?If we?need the latest Amazon Linux AMI for a specific region, use this parameter: '/aws/service/ami-amazon-linux-latest/amzn-ami-hvm-x86_64-gp2'.
The namespace contains two parts: Parameter Store Prefix (tree): /aws/service/ami-amazon-linux-latest/ and AMI name alias: amzn-ami-hvm-x86_64-gp2.
We can create a query to retrieve the latest Amazon Linux AMI ImageID value. Each region has a replica namespace that contains its region-specific ImageID value.?This?makes it easy to access the latest AMI for our region. We can use the AWS CLI to query the latest Amazon Linux AMI ImageID value by running the following command:
aws ssm get-parameters --names /aws/service/ami-amazon-linux-latest/amzn-ami-hvm-x86_64-gp2 --region us-east-1
We can use the AWS CLI to query the complete list of AWS Amazon Linux Parameter Store namespaces available by running the following command:
aws ssm get-parameters-by-path --path "/aws/service/ami-amazon-linux-latest" --region us-east-1
Here is an example of how to reference it in a CloudFormation template.
The "Resources" section of our AWS CloudFormation template defines the AWS resources that will?be created?or modified when the template?is executed. This section contains information about the infrastructure components required for your time test of various EC2 instances. It includes IAM roles, EC2 instances, and SSM documents to manage and configure these instances.?
Let's break it down:
- TestMachineIAMRole: This resource defines an IAM role that enables CloudWatch Logs and Systems Manager (SSM) access to the test. It includes?properties such as the RoleName, ManagedPolicyArns, AssumeRolePolicyDocument, and Path.
- TestMachineInstanceProfile: This resource defines an IAM Instance Profile that associates the IAM Role created above with EC2 instances. It specifies the InstanceProfileName, Path, and Roles.
- XenTestInstance: This resource is practical as it creates an Xen-based EC2 instance. It includes metadata for AWS CloudFormation initialization, such as setting up the time test script. Properties include ImageId, InstanceType, IamInstanceProfile, KeyName, SubnetId, UserData (script execution during instance launch), and Tags. This will install a program on each machine that requests the time of day from a local C-library one million times. This straightforward process allows for easy replication of the experiment.?
- KVMTestInstance: This resource creates a Nitro/KVM-based EC2 instance, similar to XenTestInstance but with different InstanceType and Tags. This will install a program on each machine that requests the time of day from a local C-library one million times. This straightforward process allows for easy replication of the experiment.?
- setTSCdocument: This resource defines an AWS Systems Manager (SSM) Document of type "Command" that sets the time source to TSC (Time Stamp Counter) for increased performance on an Xen node. This SSM document, named "setTSCdocument" improves performance on a Xen node by setting the timesource to TSC.
领英推荐
- runTestScriptdocument: This resource defines another SSM Document of type "Command" that runs a test Python script deployed on the EC2 instances. This SSM document, named "runTestSceriptdocument" will utilize the SSM tool to execute a Python script that has been installed on the EC2 instance. The purpose of the script is to perform system testing.
We have two types of Amazon EC2 instances running in the US East (N. Virginia) region: one uses Nitro/KVM technology (m5.large), and the other uses Xen technology without Nitro (m4.large).
To run the test, we can search for "Systems Manager" in the AWS Console. From there, we can go to "Instances & Nodes" and click?on?"Run Command". Then, we can select the instances?labeled?"XenTimeInstanceTest" and "KVMTimeInstanceTest" under "Targets" and click "Run". After running the test, we can check the output to see the time it took for the script to run and the syscalls used during its execution.?
Our tests revealed that the Nitro/KVM-based EC2 instance took 123.1481 seconds (about 2 minutes), while the Xen-based one took 19.6806 seconds.?
To improve the performance of the Xen-based EC2 instances, we can change the default time clock from?xen?to?tsc?(Time Stamp Counter), which is considered the best practice for Xen-based EC2 instances. We can use the following code to change the clock source:?
echo "tsc" > /sys/devices/system/clocksource/clocksource0/current_clocksource?
To verify if a change has been successful, connect to an Amazon EC2 instance. You can choose the Amazon EC2 instance based on Xen, for example, m4.large.
We enter the command 'dmesg?| less'.?If we see "clocksource: Switched to?clocksource?tsc," the change was successful.
Changing the clock source from Xen to Tsc improved the Xen-based performance from 123.1481 seconds (about 2 minutes) to 26.7693 seconds.?
By modifying the clock source for an Xen-based instance, we witnessed a significant improvement in system performance, directly influencing application performance. The Nitro system's capabilities further enhance clock timing and offload hypervisor-related tasks for specific instances. AWS System Manager, on the other hand, empowers administrators to effortlessly modify system configurations across multiple instances, thereby boosting system performance and reducing the time required for manual changes.
References:
?