Amazon RDS on Graviton2 Processors

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.

Ryzen CPU's seem to have a decent amount of cache's built in: Level 1 cache size 12 x 32 KB 8-way set associative instruction caches 12 x 32 KB 8-way set associative data caches Level 2 cache size 12 x 512 KB 8-way set associative unified caches Level 3 cache size 4 x 16 MB 16-way set associative shared caches

Of course, you can't compare those directly with epyc/xeon because of the architectural/instruction set differences.

EDIT: meaning that a larger sized cache wouldn't necessarily deliver better performance (though I think in this case the architectural differences do favor Graviton making better use of cache)

I couldn't find anything on the differences between the two different L1 caches. What's the purpose for a second L1 cache?

Same please do tell

I am trying to backup gmail emails my employees send and receive and make them searchable. This will enable a new account manager on an account to easily search and find previous discussions with clients and come up to speed to help them quickly.

We were pulling in millions of emails from the past few years, so we had to do a larger size RDS and we were killed on the IO charges.

We are now just on a medium sized EC2 server.

Do you have suggestions for better ways of doing this?

Yup, it's about 1.8x for the instance sizes I checked.

Quick explanation: 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.

We previously did a product based on the Octeon3. I feel sympathy for anyone who has to deal with Cavium's SDKs.

On one hand, it's incredibly annoying. On the other hand part of why you'd choose RDS over deploying MariaDB yourself to an EC2 instance is to shift some of the responsibility of testing & configuration over to AWS. If AWS is disabling features on instances that don't work, this is actually a benefit that they're providing to their users, as you can better trust that any feature enabled on a given product & instance type will "just work".

Is there somewhere that lists which features are enabled on which instances? We were thinking of switching to Graviton2 RDS instances but not being able to use Performance Insights would be an important factor in making or not making that switch.

You can't have usage data for a feature that doesn't exist.

From my perspective, we are fortunate to have a lot of customers and tons of feedback on what they want us to build for them. The most effective way for us to help deliver what customers want is to listen directly to their voluntary feedback. That helps us more deeply understand our customers through their individual stories and anecdotes, rather than looking at the averages that come from statistics and general surveys.

For Amazon Aurora, there are a lot of additional features in development, including offering Graviton2-powered instances. I expect that will deliver price and performance benefits for customers, but it's not the only benefit that's in the works.

It depends on the AWS product.

For the container systems e.g. ECS, EKS, Fargate they have an open roadmap where they drive much of the direction from the community:

https://github.com/aws/containers-roadmap

For others it's completely closed off. At my last company we spent tens of millions a year with AWS and they never listened to us. The account managers have zero pull.

How would known usage data help you decide how urgently customers want to use a new feature that doesn't exist yet?

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

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-421...

> Note that most cellphones run ARM, there are many years of compiler optimizations as well.

Compilation, yes, runtime for DBs? Unlikely.

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)

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

Yes, just through AWS and GCP marketplaces.

ESNI (now Encrypted Client Hello: 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.