11 ms·

Amazon RDS on Graviton2 Processors

152 points by TheGuyWhoCodes 6y ago

vosper 6y ago
So who's tested Graviton2, what were you testing it for, and what did you conclude?
- 0x202020 6y ago
  We’ve been testing a few Graviton instances since before GA and have gone “all in” with our latest release targeted for EOY. We went live with R6g (Redis) and R6gd/T4g (ES) instances at the beginning of the month. We were coming from an ancient cluster from AWS managed ES (2.3) and using their i3 elasticsearch instances so it’s been an Apples to Oranges comparison. We are running T4g/C6g/R6g K8s clusters for web servers. We do still have Postgres on R5 instances but I’m interested to check out R6g there since we can do a direct comparison
  - nelsondev 6y ago
    Regarding using c6g’s instead of i3’s to power Elasticsearch machines, could you tell me more? (We’re in the same boat, considering a switch) Specifically around hyper threading, my understanding is c6 don’t have “vCPUs”, and just have “CPUs“, so the effective number of cores doubles. Did you find similar throughput (in terms of Elasticsearch Search/Write TPS) between a virtual and real core?
    - 0x202020 6y ago
      From my POV now, the i3 instances should never be used unless you absolutely need the dedicated local storage in those amounts. The per vCPU performance is horrid in comparison to any of the modern instances (R5/M5/C5) let alone comparing those vCPUs to the actual CPU of R6g/M6g/C6g like you said. Another advantage of the Graviton processors is 50% more dedicated storage compared to equivalent Intel/AMD instances. To get enough storage we would have had to bump up to r5d/r5ad.24x or metal which when testing we also saw more “jitters” in latency on the long tail. Despite the x86 instances being larger they traded blows in different tests we had, aggregates were one thing that x86 easily beat out ARM but a lot of our aggregates come from another data source so it wasn’t a deal breaker. Overall we are happy with performance, compared to old stack we are at around 10% of the cost and I think our savings was more than 2x compared to x86 after locking in some rates. R6gd.metal (16x) vs R5d.metal (24x)
      - vosper 6y ago
        Interesting, we have an Elasticsearch cluster of around 300 i3s (and maybe soon some i3ens) I think mostly because of the NVMe storage. But yeah there's not much compute to go with all that disk space. > aggregates were one thing that x86 easily beat out ARM This is actually a lot (most?) of our ES workload, so that's a really interesting detail.
  - sandGorgon 6y ago
    How are you deploying your web servers ? I assume that is where your custom application code lives. What's the developer experience here - I have been considering cross building a docker vm for arm and deploying it. But I wasn't sure how comfortable is it. We use python, if that matters
    - 0x202020 6y ago
      We have a base Debian image maintained by our Platform/Security team (compliance) that we build our Flask apps off. Other than them forgetting to push an ARM compatible image when they update we haven’t ran into issues, but I don’t know what went in behind the scenes to get the image working if anything. I would say I’m the bridge between the infra/DevOps teams and our back end team of 12 people and as far as everyone else on the team is concerned it “just works”. Still waiting for the first big time it doesn’t
      - sandGorgon 6y ago
        Thank you so much for replying! Could you go into some details? So how do you bake your code in your base image ? I'm referring to the developer experience here : 1. do you develop on x86 (mac, win, linux)? 2. Where do you build the arm docker images ? On your laptop - is it even possible. 3. Which build CI do you use to cross build arm?
        0x202020 6y ago
        1) most of the team is on MBP 16 inch models. I know there is one and may be two on 13 inch models. 2 and 3 I’ll answer to the “best of my knowledge” but on the professional level it’s something my team doesn’t handle (I do wish I knew more!). Features get merged to dev/stage/main and trigger blue-green rolling deploys based on whatever is configured. The deploy is handled through AWS CodeDeploy (not my choice, also not my teams jurisdiction) which handles ticket validation/testing/deploying to whatever k8s cluster/manual deployment rollover if needed. I believe you can build ARM images from Docker, or at least I have a vague recollection of doing so for a Raspberry Pi, on a normal x86 machine
- new23d 6y ago
  We have. We are an egress firewall company and have been testing our product on Graviton2, privately, for some time now. The ARM builds will be GA in a couple of months but so far we've concluded that: 1. These offer an excellent price to performance ratio for an egress firewall like purpose because of low instance pricing and high network throughput. 2. For our stack written in C and Rust, any performance penalty isn't noticeable. It's basically a NAT gateway filtering by hostnames for TLS & SSH outbound.
  - jcims 6y ago
    Interesting point solution. Do you just license through the AWS Marketplace? Any issues with encrypted SNI?
    - new23d 6y ago
      Yes, just through AWS and GCP marketplaces. ESNI (now Encrypted Client Hello: https://tools.ietf.org/html/draft-ietf-tls-esni-08 https://tools.ietf.org/html/draft-ietf-tls-esni-08) is still in draft. v1 of the firewall that is currently published ignores the extension but will deny in case SNI is absent. v2, due in a couple of weeks, will actively seek presence of any of ECH extensions and deny them. This is to prevent domain-fronting style of exfiltration attempts. We expect HTTP Clients in the enterprise to not have moved over to ECH any time soon. However, the firewall has a lot of checks and balances built-in to mitigate this in the future when it arrives.
      - jcims 6y ago
        Very cool! Thanks for the details. Totally agree on lag time for rolling out ECH.
        new23d 6y ago
        Thank you! Should you be interested in the v2 preview, drop us an email (from your work email) or follow our LinkedIn page.
      - 6y ago
- stingraycharles 6y ago
  It’s a fairly boring use case, but at QuasarDB we also target ARM (some of our customers run our database on embedded devices), and AWS’ graviton processors are a godsend for CI: we can just use on-demand EC2 instances as we do with all the other architectures and OS’es.
- viraptor 6y ago
  Honeycomb team has done a large test for their infra: https://www.honeycomb.io/blog/observations-on-arm64-awss-amazon-ec2-m6g-instances/ https://www.honeycomb.io/blog/observations-on-arm64-awss-ama...
- zX41ZdbW 6y ago
  ClickHouse has been comparatively tested on Graviton2 as well as other types of ARM servers: https://clickhouse.tech/benchmark/hardware/ https://clickhouse.tech/benchmark/hardware/
surfer7837 6y ago
T4g instances are also free until the end of the year if you want to try them out.
- luhn 6y ago
  You get one t4g.micro free until the end of the year https://aws.amazon.com/blogs/aws/new-t4g-instances-burstable-performance-powered-by-aws-graviton2/ https://aws.amazon.com/blogs/aws/new-t4g-instances-burstable...
kppullin 6y ago
I'd really like to try this out on a postgres replica, however these instances don't appear in the web console at least when creating a replica from an existing x86 primary. Anyone have insight here?
- luhn 6y ago
  Are you running 12.3 or higher?
  - kppullin 6y ago
    Oof, no I missed that and had the version requirements for RDS IAM auth in my mind. Thanks!
- zimbu668 6y ago
  Could be a region thing. us-west-1 for example is notoriously slow to get new features, including this one. us-east-1 has it.
sandGorgon 6y ago
Have they enabled reserved instance pricing ? Last I checked it wasn't available in many zones (I'm asia-south-1)
- bdcravens 6y ago
  Yes. Yesterday I purchased a reserved Postgresql db.m6g instance in us-east-1 https://aws.amazon.com/rds/postgresql/pricing/#Reserved_Instances https://aws.amazon.com/rds/postgresql/pricing/#Reserved_Inst...
mcqueenjordan 6y ago
These graviton2 instances are no joke. As soon as they released, it probably became the new lowest hanging fruit for many people (from a cost efficiency standpoint). The increased L1 cache has an incredible effect on most workloads.
- api 6y ago
  ARM is smaller due to simpler instruction decoders mostly, which leaves more room for a huge cache in the transistor budget. I am hoping Apple does this with their desktop chips: basically take the fastest phone/tablet processor, give it better thermals, and pump up the cache. That would be an easy path to beating Intel on a laptop.
  - nicoburns 6y ago
    My understanding was that large cache was mostly a cost tradeoff, and that there's no technical reason why x86 processors couldn't do this too. I believe Apple's A-series chips already have a huge cache which is a big part of why they are so fast.
    - opencl 6y ago
      Cost/die size is part of the consideration especially for L3 but with L1 and L2 it is much more about latency than cost: bigger caches will have higher latency than smaller ones. That's the entire reason for the multi-level cache hierarchy to exist in the first place. Graviton2 doesn't even have a particularly large total amount of cache, the only part of the cache system that's bigger than both AMD and Intel is the L1D. L1I is the same as AMD, L2 is same as Intel, L3 is smaller than both (talking about current-gen server chips). That L1D can indeed make a big difference in certain workloads though. The L3 is actually pretty small for how many cores there are, ARM recommends 1-2MB/core for the N1 cores in the Graviton2 and it has 512KB/core. AMD has 4MB per core in Zen2 albeit with a slightly weird setup where the L3 is localized to 4 core clusters.
      - savanx 6y ago
aidos 6y ago
Are there any gotchas with using these machines for general workloads? Are there compatibility issues you need to be aware of? Can I just run a Postgres instance on them and expect everything to work?
etaioinshrdlu 6y ago
It kind of peeves me how often in RDS, the available machine instance types have vastly differing available RDS features. Here, for example, Amazon's own Aurora MySQL is not available on Graviton processors.
- foobiekr 6y ago
  Most multithreaded software has concurrency bugs and many of those bugs have been covered up for years by the relatively friendlier x86 memory model vs weaker models like ARM. It is not surprising at all that supported products are going to be slow to support other architecture.
  - aidos 6y ago
    Ooooh interesting. Any more info about the difference in models and how it causes this effect?
    - jeffbee 6y ago
      Quick explanation: https://www.cs.utexas.edu/~bornholt/post/memory-models.html https://www.cs.utexas.edu/~bornholt/post/memory-models.html Basically, although I'm sure someone will shout me down for this, x86 provides something close to sequential consistency among loads and stores even for concurrent programs, whereas ARM and POWER provide almost no kind of order for loads and stores without barriers. High-level languages like C++ do not really hide this problem. It is very easy to write a concurrent C++ program on x86 that appears to work in practice but never works on ARM.
      - my123 6y ago
        You need proper memory model handling for the program to be compliant even for x86. If you do it otherwise and you see that it works for you, keep in mind that the compiler is allowed to reorder in that case, which can result in very odd breakage. On x86, sequential consistency isn't the implemented memory model, but rather total store ordering. Stores are buffered inside the core and the guarantee provided is that they'll appear to other cores in the proper order. On SC designs, all the cores have the same view of coherent memory all the time. In such a design, barriers aren't required and are lowered down to NOPs. (only general-purpose processors that I know of that implement sequential consistency are NVIDIA's Tegra K1 (64-bit variant) and Tegra Xavier)
deleted 6y ago
[deleted]
ilaksh 6y ago
I didn't see a link to the pricing for these.
- durkie 6y ago
  I saw it here: https://aws.amazon.com/rds/pricing/ https://aws.amazon.com/rds/pricing/ Pricing was available for Postgres, but I didn't check other database types
  - nicoburns 6y ago
    https://ec2instances.info/rds/?cost_duration=monthly https://ec2instances.info/rds/?cost_duration=monthly is great for comparing prices of different AWS instances.
jeffbee 6y ago
Competitive benchmarks conspicuously absent. I would expect a vendor who controls both the hardware and the application build to easily show that graviton2+rds is beating the pants off percona builds on x86, but I don't see any claims here.
- liquid153 6y ago
  Would be nice. Raw power isn’t everything 20+ years of software optimization on x86 gives it a nice lead. Wonder how long it will take to close that gap. Or if AWS engineers are/have been submitting PRs to the popular open source dbs
  - tpetry 6y ago
    AWS engineers most often fork the open source repositories and keep sll their patches only to them, they rarely submit those upstream.
    - _msw_ 6y ago
      Disclosure: I work at AWS where I build the cloud infrastructure that powers EC2. One example of a patch that can help with MySQL performance on Graviton2 processors is enabling the Large System Extension atomic operations. You can find our pull request for enabling that here: https://github.com/mysql/mysql-server/pull/302 https://github.com/mysql/mysql-server/pull/302 Unfortunately it seems that their CLA bot auto-closed the submission. Thank you for your comment here on HN, because it prompted me to go check on this PR and it led me to this discovery. [edit] See also the discussion here about compiler flag defaults for PostgreSQL, to provide optimizations while retaining compatibility for Arm processors without LSE: https://www.postgresql.org/message-id/flat/099F69EE-51D3-4214-934A-1F28C0A1A7A7%40amazon.com https://www.postgresql.org/message-id/flat/099F69EE-51D3-421...
      - jeffbee 6y ago
        AWS provides the binary for RDS users, right? Why do you need to block on upstream for these improvements?
aeyes 6y ago
How likely is it for AWS to come up with instance types offering more cores than x86? It seems like with Intel we'll be stuck at 96 cores for at least the next generation. 128 or more cores would spark my interest, especially on RDS. Graviton2 is built on Neoverse N1 which already has a reference design featuring 128 cores. N2 supports 192 cores.
asah 6y ago
omg. I tried to benchmark g2 on my dev/test workload and it was so much faster, I ended the test early and simply migrated over to g2. Untold story: open source and CI is now sufficiently pervasive, that recompiling for ARM just isn't a big deal. Gone are the days of painful recompiles. tl;dr: remember your first experience with SSD vs HD? that's what the g2 performance boost feels like.

vosper 6y ago

So who's tested Graviton2, what were you testing it for, and what did you conclude?

0x202020 6y ago
We’ve been testing a few Graviton instances since before GA and have gone “all in” with our latest release targeted for EOY. We went live with R6g (Redis) and R6gd/T4g (ES) instances at the beginning of the month. We were coming from an ancient cluster from AWS managed ES (2.3) and using their i3 elasticsearch instances so it’s been an Apples to Oranges comparison. We are running T4g/C6g/R6g K8s clusters for web servers. We do still have Postgres on R5 instances but I’m interested to check out R6g there since we can do a direct comparison
- nelsondev 6y ago
  Regarding using c6g’s instead of i3’s to power Elasticsearch machines, could you tell me more? (We’re in the same boat, considering a switch) Specifically around hyper threading, my understanding is c6 don’t have “vCPUs”, and just have “CPUs“, so the effective number of cores doubles. Did you find similar throughput (in terms of Elasticsearch Search/Write TPS) between a virtual and real core?
  - 0x202020 6y ago
    From my POV now, the i3 instances should never be used unless you absolutely need the dedicated local storage in those amounts. The per vCPU performance is horrid in comparison to any of the modern instances (R5/M5/C5) let alone comparing those vCPUs to the actual CPU of R6g/M6g/C6g like you said. Another advantage of the Graviton processors is 50% more dedicated storage compared to equivalent Intel/AMD instances. To get enough storage we would have had to bump up to r5d/r5ad.24x or metal which when testing we also saw more “jitters” in latency on the long tail. Despite the x86 instances being larger they traded blows in different tests we had, aggregates were one thing that x86 easily beat out ARM but a lot of our aggregates come from another data source so it wasn’t a deal breaker. Overall we are happy with performance, compared to old stack we are at around 10% of the cost and I think our savings was more than 2x compared to x86 after locking in some rates. R6gd.metal (16x) vs R5d.metal (24x)
    - vosper 6y ago
      Interesting, we have an Elasticsearch cluster of around 300 i3s (and maybe soon some i3ens) I think mostly because of the NVMe storage. But yeah there's not much compute to go with all that disk space. > aggregates were one thing that x86 easily beat out ARM This is actually a lot (most?) of our ES workload, so that's a really interesting detail.
- sandGorgon 6y ago
  How are you deploying your web servers ? I assume that is where your custom application code lives. What's the developer experience here - I have been considering cross building a docker vm for arm and deploying it. But I wasn't sure how comfortable is it. We use python, if that matters
  - 0x202020 6y ago
    We have a base Debian image maintained by our Platform/Security team (compliance) that we build our Flask apps off. Other than them forgetting to push an ARM compatible image when they update we haven’t ran into issues, but I don’t know what went in behind the scenes to get the image working if anything. I would say I’m the bridge between the infra/DevOps teams and our back end team of 12 people and as far as everyone else on the team is concerned it “just works”. Still waiting for the first big time it doesn’t
    - sandGorgon 6y ago
      Thank you so much for replying! Could you go into some details? So how do you bake your code in your base image ? I'm referring to the developer experience here : 1. do you develop on x86 (mac, win, linux)? 2. Where do you build the arm docker images ? On your laptop - is it even possible. 3. Which build CI do you use to cross build arm?
      - 0x202020 6y ago
        1) most of the team is on MBP 16 inch models. I know there is one and may be two on 13 inch models. 2 and 3 I’ll answer to the “best of my knowledge” but on the professional level it’s something my team doesn’t handle (I do wish I knew more!). Features get merged to dev/stage/main and trigger blue-green rolling deploys based on whatever is configured. The deploy is handled through AWS CodeDeploy (not my choice, also not my teams jurisdiction) which handles ticket validation/testing/deploying to whatever k8s cluster/manual deployment rollover if needed. I believe you can build ARM images from Docker, or at least I have a vague recollection of doing so for a Raspberry Pi, on a normal x86 machine
new23d 6y ago
We have. We are an egress firewall company and have been testing our product on Graviton2, privately, for some time now. The ARM builds will be GA in a couple of months but so far we've concluded that: 1. These offer an excellent price to performance ratio for an egress firewall like purpose because of low instance pricing and high network throughput. 2. For our stack written in C and Rust, any performance penalty isn't noticeable. It's basically a NAT gateway filtering by hostnames for TLS & SSH outbound.
- jcims 6y ago
  Interesting point solution. Do you just license through the AWS Marketplace? Any issues with encrypted SNI?
  - new23d 6y ago
    Yes, just through AWS and GCP marketplaces. ESNI (now Encrypted Client Hello: https://tools.ietf.org/html/draft-ietf-tls-esni-08 https://tools.ietf.org/html/draft-ietf-tls-esni-08) is still in draft. v1 of the firewall that is currently published ignores the extension but will deny in case SNI is absent. v2, due in a couple of weeks, will actively seek presence of any of ECH extensions and deny them. This is to prevent domain-fronting style of exfiltration attempts. We expect HTTP Clients in the enterprise to not have moved over to ECH any time soon. However, the firewall has a lot of checks and balances built-in to mitigate this in the future when it arrives.
    - jcims 6y ago
      Very cool! Thanks for the details. Totally agree on lag time for rolling out ECH.
      - new23d 6y ago
        Thank you! Should you be interested in the v2 preview, drop us an email (from your work email) or follow our LinkedIn page.
    - 6y ago
stingraycharles 6y ago
It’s a fairly boring use case, but at QuasarDB we also target ARM (some of our customers run our database on embedded devices), and AWS’ graviton processors are a godsend for CI: we can just use on-demand EC2 instances as we do with all the other architectures and OS’es.
viraptor 6y ago
Honeycomb team has done a large test for their infra: https://www.honeycomb.io/blog/observations-on-arm64-awss-amazon-ec2-m6g-instances/ https://www.honeycomb.io/blog/observations-on-arm64-awss-ama...
zX41ZdbW 6y ago
ClickHouse has been comparatively tested on Graviton2 as well as other types of ARM servers: https://clickhouse.tech/benchmark/hardware/ https://clickhouse.tech/benchmark/hardware/

surfer7837 6y ago

T4g instances are also free until the end of the year if you want to try them out.

luhn 6y ago
You get one t4g.micro free until the end of the year https://aws.amazon.com/blogs/aws/new-t4g-instances-burstable-performance-powered-by-aws-graviton2/ https://aws.amazon.com/blogs/aws/new-t4g-instances-burstable...

kppullin 6y ago

I'd really like to try this out on a postgres replica, however these instances don't appear in the web console at least when creating a replica from an existing x86 primary. Anyone have insight here?

luhn 6y ago
Are you running 12.3 or higher?
- kppullin 6y ago
  Oof, no I missed that and had the version requirements for RDS IAM auth in my mind. Thanks!
zimbu668 6y ago
Could be a region thing. us-west-1 for example is notoriously slow to get new features, including this one. us-east-1 has it.

sandGorgon 6y ago

Have they enabled reserved instance pricing ? Last I checked it wasn't available in many zones (I'm asia-south-1)

bdcravens 6y ago
Yes. Yesterday I purchased a reserved Postgresql db.m6g instance in us-east-1 https://aws.amazon.com/rds/postgresql/pricing/#Reserved_Instances https://aws.amazon.com/rds/postgresql/pricing/#Reserved_Inst...

mcqueenjordan 6y ago

These graviton2 instances are no joke. As soon as they released, it probably became the new lowest hanging fruit for many people (from a cost efficiency standpoint). The increased L1 cache has an incredible effect on most workloads.

api 6y ago
ARM is smaller due to simpler instruction decoders mostly, which leaves more room for a huge cache in the transistor budget. I am hoping Apple does this with their desktop chips: basically take the fastest phone/tablet processor, give it better thermals, and pump up the cache. That would be an easy path to beating Intel on a laptop.
- nicoburns 6y ago
  My understanding was that large cache was mostly a cost tradeoff, and that there's no technical reason why x86 processors couldn't do this too. I believe Apple's A-series chips already have a huge cache which is a big part of why they are so fast.
  - opencl 6y ago
    Cost/die size is part of the consideration especially for L3 but with L1 and L2 it is much more about latency than cost: bigger caches will have higher latency than smaller ones. That's the entire reason for the multi-level cache hierarchy to exist in the first place. Graviton2 doesn't even have a particularly large total amount of cache, the only part of the cache system that's bigger than both AMD and Intel is the L1D. L1I is the same as AMD, L2 is same as Intel, L3 is smaller than both (talking about current-gen server chips). That L1D can indeed make a big difference in certain workloads though. The L3 is actually pretty small for how many cores there are, ARM recommends 1-2MB/core for the N1 cores in the Graviton2 and it has 512KB/core. AMD has 4MB per core in Zen2 albeit with a slightly weird setup where the L3 is localized to 4 core clusters.
    - savanx 6y ago

aidos 6y ago

Are there any gotchas with using these machines for general workloads? Are there compatibility issues you need to be aware of? Can I just run a Postgres instance on them and expect everything to work?

etaioinshrdlu 6y ago

It kind of peeves me how often in RDS, the available machine instance types have vastly differing available RDS features. Here, for example, Amazon's own Aurora MySQL is not available on Graviton processors.

foobiekr 6y ago
Most multithreaded software has concurrency bugs and many of those bugs have been covered up for years by the relatively friendlier x86 memory model vs weaker models like ARM. It is not surprising at all that supported products are going to be slow to support other architecture.
- aidos 6y ago
  Ooooh interesting. Any more info about the difference in models and how it causes this effect?
  - jeffbee 6y ago
    Quick explanation: https://www.cs.utexas.edu/~bornholt/post/memory-models.html https://www.cs.utexas.edu/~bornholt/post/memory-models.html Basically, although I'm sure someone will shout me down for this, x86 provides something close to sequential consistency among loads and stores even for concurrent programs, whereas ARM and POWER provide almost no kind of order for loads and stores without barriers. High-level languages like C++ do not really hide this problem. It is very easy to write a concurrent C++ program on x86 that appears to work in practice but never works on ARM.
    - my123 6y ago
      You need proper memory model handling for the program to be compliant even for x86. If you do it otherwise and you see that it works for you, keep in mind that the compiler is allowed to reorder in that case, which can result in very odd breakage. On x86, sequential consistency isn't the implemented memory model, but rather total store ordering. Stores are buffered inside the core and the guarantee provided is that they'll appear to other cores in the proper order. On SC designs, all the cores have the same view of coherent memory all the time. In such a design, barriers aren't required and are lowered down to NOPs. (only general-purpose processors that I know of that implement sequential consistency are NVIDIA's Tegra K1 (64-bit variant) and Tegra Xavier)

deleted 6y ago

[deleted]

ilaksh 6y ago

I didn't see a link to the pricing for these.

durkie 6y ago
I saw it here: https://aws.amazon.com/rds/pricing/ https://aws.amazon.com/rds/pricing/ Pricing was available for Postgres, but I didn't check other database types
- nicoburns 6y ago
  https://ec2instances.info/rds/?cost_duration=monthly https://ec2instances.info/rds/?cost_duration=monthly is great for comparing prices of different AWS instances.

jeffbee 6y ago

Competitive benchmarks conspicuously absent. I would expect a vendor who controls both the hardware and the application build to easily show that graviton2+rds is beating the pants off percona builds on x86, but I don't see any claims here.

liquid153 6y ago
Would be nice. Raw power isn’t everything 20+ years of software optimization on x86 gives it a nice lead. Wonder how long it will take to close that gap. Or if AWS engineers are/have been submitting PRs to the popular open source dbs
- tpetry 6y ago
  AWS engineers most often fork the open source repositories and keep sll their patches only to them, they rarely submit those upstream.
  - _msw_ 6y ago
    Disclosure: I work at AWS where I build the cloud infrastructure that powers EC2. One example of a patch that can help with MySQL performance on Graviton2 processors is enabling the Large System Extension atomic operations. You can find our pull request for enabling that here: https://github.com/mysql/mysql-server/pull/302 https://github.com/mysql/mysql-server/pull/302 Unfortunately it seems that their CLA bot auto-closed the submission. Thank you for your comment here on HN, because it prompted me to go check on this PR and it led me to this discovery. [edit] See also the discussion here about compiler flag defaults for PostgreSQL, to provide optimizations while retaining compatibility for Arm processors without LSE: https://www.postgresql.org/message-id/flat/099F69EE-51D3-4214-934A-1F28C0A1A7A7%40amazon.com https://www.postgresql.org/message-id/flat/099F69EE-51D3-421...
    - jeffbee 6y ago
      AWS provides the binary for RDS users, right? Why do you need to block on upstream for these improvements?

aeyes 6y ago

How likely is it for AWS to come up with instance types offering more cores than x86? It seems like with Intel we'll be stuck at 96 cores for at least the next generation. 128 or more cores would spark my interest, especially on RDS. Graviton2 is built on Neoverse N1 which already has a reference design featuring 128 cores. N2 supports 192 cores.

asah 6y ago

omg. I tried to benchmark g2 on my dev/test workload and it was so much faster, I ended the test early and simply migrated over to g2. Untold story: open source and CI is now sufficiently pervasive, that recompiling for ARM just isn't a big deal. Gone are the days of painful recompiles. tl;dr: remember your first experience with SSD vs HD? that's what the g2 performance boost feels like.