We currently run six ra3.4xlarge nodes that handle frequent data imports. CPU utilization is often below 10%, but the loads still take a while because they involve uploading many separate files. If we resized to smaller ra3.large or ra3.xlarge nodes while keeping roughly the same total CPU and memory, could the workload be distributed more efficiently and finish faster? We plan to benchmark it, but I'd appreciate insight into whether this approach is likely to help or whether file layout, I/O, or load parallelism is the bigger factor.
3 Answers
Low CPU usage by itself doesn’t indicate that smaller nodes will load data faster. COPY performance is often limited by file parallelism and I/O rather than CPU. Check that the files are similarly sized, preferably within AWS’s recommended range of roughly 1 MB to 1 GB after compression, and that the file count provides enough work for the cluster’s slices. Once the files are optimized, benchmark an elastic resize, since smaller nodes could have less I/O throughput even if the aggregate CPU and memory appear comparable.
It’s worth comparing the cost and capacity of alternative configurations too. A different node mix may provide similar or greater aggregate CPU and memory at a lower hourly rate, while serverless could be useful for intermittent workloads if a startup delay of around 15–30 seconds is acceptable. Reserved capacity may complicate the change, so check whether your reservation can be exchanged or applied to the new configuration.
For loads from object storage, Spectrum task parallelism may be the limiting factor. An ra3.4xlarge has 12 slices, with up to 10 Spectrum tasks per slice, so six nodes could theoretically support up to 720 concurrent tasks. Verify the actual slice count in the system tables, especially if the cluster has been resized before. If the current slice count is unexpectedly low, a classic resize might improve distribution more than simply switching node sizes.
Thanks, that’s helpful. We already have reserved capacity, so changing configurations would depend on whether the reservation can be exchanged or otherwise applied to the new nodes.