-
Notifications
You must be signed in to change notification settings - Fork 582
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
rpk: add newer EC2 instance types #17220
rpk: add newer EC2 instance types #17220
Conversation
Still testing this one but thought I'd throw the review up. |
Add more EC2 instance types to the "well known IO" mapping, which maps an instance type to the seastar IO scheduler parameters associted with the local SSD performance for that instance. This change includes iotune numbers for i4i, is4gen and im4gn. iotune did show an unusual sloping off of performance at the highest instance sizes, so beyond some threshold we just mulitply the measurement from the last-good instance type by the instance size multiplier: this is similar to what we were doing for the existing instance i3en. Issue redpanda-data#13582.
c31d4a1
to
dbcff69
Compare
This is ready for review. I tested it on im4gn and confirmed that the expected io-properties are passed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thank you!
// The measured values for is4gen.8xlarge broke the expected pattern | ||
// and compared to 4xlarge for IOPS were slightly lower (!!) on the read side and | ||
// only slightly higher on the write side, rather than the expected 2x | ||
// jump. Signs point towards a measurement limitation rather than a real |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For my own understanding, what would be the theoretical impact if it is not a measurement limitation?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well for one it would mean that the instances cannot achieve their advertised performance, which is something to bring up with the cloud vendor I guess. From a practical impact it means that the performance ceiling would be lower than expected on those instance types, but for the most part the gap was small enough that it doesn't necessarily impact performance at the levels expected in our tiers.
Of course I wouldn't expect anyway to simply accept my hand-wavy explanation that this is measurement error and "probably fine" indefinitely :), so here's the follow up: #17261
new failures in https://buildkite.com/redpanda/redpanda/builds/46600#018e641f-6382-4211-bb5c-c80639bfae6f:
|
ducktape was retried in https://buildkite.com/redpanda/redpanda/builds/46600#018e6431-f6af-4c0d-bd7a-2b3c662612ed |
/backport v23.3.x |
Add more EC2 instance types to the "well known IO" mapping, which maps an instance type to the seastar IO scheduler parameters associted with the local SSD performance for that instance.
This change includes iotune numbers for i4i, is4gen and im4gn. iotune did show an unusual sloping off of performance at the highest instance sizes, so beyond some threshold we just mulitply the measurement from the last-good instance type by the instance size multiplier: this is similar to what we were doing for the existing instance i3en.
Issue #13582.
Backports Required
Release Notes
Improvements
rpk redpanda start
know knows about io characteristics on EC2 instance types i4i, is4gen and im4gn in addition to i3en and i3, allowing more effective IO scheduling even ifrpk iotune
has not been run.