My Amazon Elastic Compute Cloud (Amazon EC2) macOS instance has slow processing speeds when it invokes, updates, or renders data, or when it runs applications. Or, the macOS instance that I launched with an Amazon Elastic Block Store (Amazon EBS) snapshot has slow performance.
Resolution
Check your APFS configuration
Silicon devices such as ARM-based M1 and M2 chips use the Apple File System (APFS), high-performance cores (P cores), and high-efficiency cores (E cores) to optimize performance. The devices use P cores for high-intensity workloads that consume large quantities of power or resources only. E cores are for less demanding workloads to reduce resource use and handle tasks such as light applications or web browsing. For more information, see Optimize for Apple Silicon with performance and efficiency cores on the Apple website. Work directly with the APFS to optimize your workstations. For more information, see Tuning your code's performance for Apple Silicon on the Apple website.
When you launch the instance, select a dedicated host that meets your performance requirements
When you allocate a dedicated host, make sure that you select the resource that best meets your architectural needs. Use mac1 and mac2 for standard workloads, and use mac2-m1ultra.metal, mac2-m2.metal, and mac2-m2pro.metal for additional processing power.
When you launch the instance, select an Amazon EBS device that meets your performance requirements
Your Amazon EBS settings affect the overall performance of the APFS. As the default file system for macOS, APFS is optimized for SSD storage. As a result, it's a best practice to use an SSD-backed EBS volume, such as gp3 or io. Or, review each EBS volume type to identify the volume that meets your environment needs. It's a best practice to start with a configuration that uses 5000 IOPS and 200 throughput.
After you restore an instance, initialize the instance to avoid lazy loading
When you use a snapshot to restore an EBS volume, Amazon EBS pulls your data from Amazon Simple Storage Service (Amazon S3). This initialization period when Amazon EBS is warming up your disk depends on the disk size, EBS volume, and data type. With lazy loading, Amazon EBS reads data from the snapshot and restores it as needed. If you access unloaded data from a newly launched disk, then you experience high latency. To avoid lazy loading, manually initialize the volume and run the fio or dd command:
fio --filename=/dev/device --rw=read --bs=128k --iodepth=32 -- ioengine=libaio --direct=1 --name=volume-initialize
Note: It's a best practice to use fio. However, if fio isn't available on your device, then use dd.
-or-
dd if=/dev/deviceName of=/dev/null bs=1M
Note: Replace device or deviceName with the disk name.
Or, use fast snapshot restore (FSR).
The manual initialization process can take several hours, depending on the disk size and data type. However, the process is faster than when Amazon EBS initializes your disk. After manual initialization completes, the disk is "pre-warmed" and ready to use.