Skip to content

Network problem with EC2 instance

0

Hi, I'm seeing a strange behavior with one of our instances - the network data to and from the server is delayed sometimes up to 30-40 seconds. Our application is time sensitive and when there's a delay from the client to the server a state resync must happen. Several clients from around the world started complaining, because of resyncs. Recently, I managed to hit a similar "network" problem while I was connected to the server via SSH. I had the "top" command running and suddenly the output froze. I waited for 20-30 seconds, but it stayed frozen. The moment I opened a second SSH session, the first console unfroze and started outputting data again. This happened several times and every time I opened a new connection, the original connection started working. I believe this is a network problem, because the server is not overloaded. It's a m6g.2xlarge instance with 8 cores and the load is around 0.66, 0.55, 0.48. This issue is rare, but today it happens very often.

2 Answers
1

The issue you're experiencing with your EC2 instance seems to be related to network performance rather than server load. Given that you're using an m6g.2xlarge instance and the load averages are relatively low, it's unlikely that the problem is due to CPU or memory constraints.

There are a few potential causes and solutions to consider:

  1. Network I/O credit mechanism: Some EC2 instances, particularly those with fewer than 16 vCPUs, use a network I/O credit system. When an instance exceeds its baseline bandwidth, it can experience temporary network performance issues. However, an m6g.2xlarge should have sufficient network performance for most applications.

  2. Packet loss: The symptoms you describe could be indicative of packet loss. AWS provides tools to monitor network performance, including packet loss. You can use CloudWatch metrics to monitor instance network bandwidth and packets sent and received. The Elastic Network Adapter (ENA) driver also provides network performance metrics that can help identify when traffic exceeds AWS-defined network allowances.

  3. Microburst traffic: Short spikes in network demand (microbursts) can cause temporary network issues that may not be reflected in standard CloudWatch metrics due to their granularity.

  4. Connection keepalives: The behavior you're seeing with SSH sessions could be related to connection timeouts. Ensuring that keepalives are enabled for your connections might help prevent disconnections.

To troubleshoot and potentially resolve the issue:

  1. Monitor network performance metrics using CloudWatch and ENA driver metrics to identify any patterns or spikes in network usage.

  2. Check if your instance is consistently exceeding its baseline network bandwidth.

  3. Consider enabling keepalives for your connections, including SSH. For example, in PuTTY, you can set the "Seconds between keepalives" to 59 seconds to prevent disconnections.

  4. If the issue persists, you may want to consider upgrading to an instance type with higher network performance or reaching out to AWS support for further investigation.

Remember that network performance can be affected by factors outside of the instance itself, such as the overall network conditions between your clients and the AWS infrastructure. If the problem continues, it may be worth investigating potential issues with routing or internet connectivity between your clients and the AWS region where your instance is hosted.
Sources
Amazon EC2 instance network bandwidth - Amazon Elastic Compute Cloud
Troubleshoot issues connecting to your Amazon EC2 Linux instance - Amazon Elastic Compute Cloud

answered 2 years ago

AWS
EXPERT

reviewed 8 months ago

0

In addition to general recommendations stated above, it's also recommended to run some tests from different client locations into the server running your application, one useful tool that may help you validate roundtrip latency from client to application server is https://aws-latency-test.com/

Depending on the region your server is located at, you could also implement mechanisms such as AWS Global Accelerator or Amazon CloudFront to elevate performance and availability of your application to clients located in different geographic locations. Global Accelerator is better for non-HTTP use cases, like gaming, IoT, and Voice over IP, while CloudFront is better for HTTP/HTTPS content. Global Accelerator supports TCP and UDP protocols, while CloudFront supports HTTP and WebSocket protocols. CloudFront caches content at edge locations, while Global Accelerator uses edge locations to find the best path to the nearest regional endpoint. Global Accelerator provides static IP addresses, while CloudFront uses multiple sets of dynamically changing IP addresses.

Sources

https://aws.amazon.com/global-accelerator/faqs/

https://medium.com/@minimaldevops/differences-between-global-accelerator-and-cloudfront-in-aws-b6a4d76cb6ff#:~:text=CloudFront%20utilizes%20edge%20locations%20to,and%20lower%20latency%20for%20applications.

AWS

answered 2 years ago

AWS
EXPERT

reviewed 8 months ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.