Migrating from RDS SQL Server db.r5d.large to t3.xlarge - Confirming No Local Storage Usage

Question

Hi everyone,

I'm planning to migrate my RDS SQL Server instance from a db.r5d.large to a t3.xlarge instance for potential cost savings and improved performance based on my current average CPU usage. However, I want to ensure a smooth transition and avoid any storage-related issues.

My question:

How can I definitively confirm that my current db.r5d.large instance is not utilizing the local NVMe SSD storage? I'd like to be confident that migrating to a t3.xlarge instance (which doesn't offer local storage) won't cause any unexpected performance impacts during the CPU spikes I experience twice a day, which reach 80-90% and 40-50% utilization respectively.

Information I've Gathered:
I've reviewed the RDS CloudWatch metrics (ReadIOPSLocalStorage, ReadThroughputLocalStorage, ReadLatencyLocalStorage) and observed occasional spikes, but I understand these might not directly indicate local storage usage.
I'm currently investigating my database configuration files for potential references to local storage paths.

If my application does require local storage, I understand migrating to a db.m5d.large instance (with 8 GiB RAM and local storage) could be an alternative, but with potentially higher costs than a t3.xlarge.

I appreciate any insights or advice the community can offer to ensure a successful migration without storage-related concerns.

Pandu · Accepted Answer

Hi Adit,

please go through the below steps i hope it will helps to resolve your issue.

**Check Storage Configuration in RDS:**

* Look at the instance's configuration in the RDS console to see if it explicitly mentions using NVMe SSDs for storage. The db.r5d.large instance type includes local NVMe SSD storage, but it's important to confirm how this is configured for your instance.

**Analyze CloudWatch Metrics:**

* You've already looked at CloudWatch metrics like ReadIOPSLocalStorage, ReadThroughputLocalStorage, and ReadLatencyLocalStorage. Occasional spikes in these metrics suggest some level of local storage usage. However, you should correlate these spikes with your application's peak usage times to understand the impact.

**Review Database Configuration Files:**

**Investigate SQL Server configuration files or run queries to check for any database files, tempdb, or logs that are located on local storage paths. For SQL Server, you can run a query like:**

```
SELECT name, physical_name, type_desc
FROM sys.master_files;
```

This will list all the files and their locations. If any of these paths point to local NVMe storage, migrating to an instance without local storage could impact performance.

**Evaluate Performance Metrics:**

* Beyond storage metrics, evaluate overall performance metrics, including CPU, memory, and I/O performance, especially during the periods of CPU spikes. Understanding the resource utilization pattern will help in making a more informed decision.

**Consider the Application Workload:**

* Assess the type of workload your application is handling. If it's I/O intensive and benefits significantly from low-latency NVMe SSDs, then switching to an instance without local storage might degrade performance.

**Steps to Mitigate Potential Performance Issues:**

**Test Migration:**

* Before fully migrating, consider creating a snapshot of your current instance and restoring it to a t3.xlarge instance. This will allow you to test the performance under your typical workload without impacting the production environment.

**Monitoring Post-Migration:**

* After migration, closely monitor the new instance's performance metrics to ensure there are no unexpected issues. Pay particular attention to CPU, memory, and I/O metrics.

**Alternative Instance Type:**

* If testing shows performance issues with t3.xlarge, consider the db.m5d.large instance type as it includes local NVMe storage, albeit at a potentially higher cost.

**Adjust SQL Server Configuration:**

* Optimize your SQL Server configuration to better handle the absence of local storage. This might involve tweaking tempdb settings, buffer pool size, or I/O settings to better utilize the available resources.

**Database Tuning:**

* Perform database tuning and indexing to reduce I/O demands. Optimized queries and indexes can significantly reduce the load on storage and improve overall performance.

**Please go through the below aws documentation links.**

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Concepts.DBInstanceClass.html

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/MonitoringOverview.html

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/monitoring-cloudwatch.html

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/Welcome.html

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_PIOPS.StorageTypes.html

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html

Didier Durand · Answer

Hi,

If you want to work directly at physical level, you can connect to the instance and use Linux command like iostat giving you all details about disk activity

See https://www.geeksforgeeks.org/iostat-command-in-linux-with-examples/

```
$ iostat -x 1
Linux 3.5.2-x86_64-linode26 (linode)    11/08/2012      _x86_64_        (4 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.84    0.00    0.08    1.22    0.07   97.80

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
xvda              0.09     1.02    2.58    0.49   112.79    12.11    40.74     0.15   48.56   3.88   1.19
xvdb              1.39     0.43    4.03    1.82    43.33    18.43    10.56     0.66  112.73   1.93   1.13
```

Best.

Didier

Migrating from RDS SQL Server db.r5d.large to t3.xlarge - Confirming No Local Storage Usage

Add your answer

Relevant content