[HN Gopher] PostgreSQL on ARM-Based AWS EC2 Instances
___________________________________________________________________
PostgreSQL on ARM-Based AWS EC2 Instances
Author : timf
Score : 99 points
Date : 2021-01-22 19:35 UTC (3 hours ago)
(HTM) web link (www.percona.com)
(TXT) w3m dump (www.percona.com)
| zaptheimpaler wrote:
| Does anyone know if/when ARM is coming to GCP? Seems like a no-
| brainer for many use cases and our company would love to move,
| but we don't have the resources to manage multiple clouds for
| now.
| legoogyawaworht wrote:
| As of around 2020H2 Google had nothing in the works for their
| own main CPU hardware. The ASIC engineers there are mostly
| focused on proprietary ML hardware like dragonfish, positron
| etc that have more comparative advantage to do in-house.
| lfittl wrote:
| When using pre-built Postgres packages on modern ARM platforms,
| like the author of this post is, double check that the Postgres
| binaries are actually using the ARMv8.2 assembly instructions.
|
| This can make a significant performance difference, and at least
| for the RPM-based official Postgres packages this is a problem:
| https://www.postgresql.org/message-id/CACN56%2BP1astF5zvocrT...
| Thaxll wrote:
| Since DB are very often "single" instance you should use what
| scale vertically best which is x86 based.
| yjftsjthsd-h wrote:
| single instance != single core/thread
| jpitz wrote:
| I would have liked to have seen a comparative bonnie++ benchmark
| - those SSDs are not the same.
| fb03 wrote:
| Has anyone here made the jump? I'm considering testing some
| components or our infrastructure on Gravitron processors but
| going all the way in with the database sounds risky but I don't
| really have a technical data point to justify my bias.
| philipkglass wrote:
| I made the jump on one of my databases soon after Graviton 2
| was officially supported on RDS. I'm running a small (~500 GB
| stored data) DB on db.m6g.large with PG 12.4. It's a tiny bit
| cheaper and performs modestly better than the Intel based
| instance it was running on before. There haven't been any
| problems or externally visible changes since the switch.
| random5634 wrote:
| For my side projects waiting for them to do the burstable /
| cheaper versions in RDS. It's a bit funny that the cheaper chip
| is not available in the cheaper instance options - seems like
| that would be a good market (whoever is too cheap to do M
| instances etc).
|
| Edit: T4g's are available on EC2.
| acdha wrote:
| I moved ElastiCache & RDS instances over. A bit faster, a bit
| cheaper exactly as expected and no time required other than a
| "terraform apply".
| uncledave wrote:
| I've played with graviton instances and compiled a few bits of
| C I use for benchmarking. Not a scientific test but I found
| them to be good but nowhere near the performance per core as
| the intel offerings. As a comparison they are nowhere near the
| Apple M1 either. But that doesn't mean they're a bad option.
|
| I think they end up close to same price/performance as the
| Intel offerings as well once you invoke the compiler optimiser.
| The main benefit is better core scalability and lower energy
| usage which may work out as a net gain for database workloads.
|
| As always it's best to measure these things yourself with your
| expected workload.
| luhn wrote:
| Gravitron's value prop is you get 2x the physical cores for a
| slightly cheaper price. Intel wins at single-thread
| performance, but for parallel workloads Intel's hyperthreaded
| vCPUs can't keep up.
|
| But you're right in that in the end it all depends on your
| workload.
| NikolaeVarius wrote:
| I use it with RDS. If something fucks up, you can always blame
| AWS. Otherwise have had no issues with it.
| Alex3917 wrote:
| > Has anyone here made the jump?
|
| Waiting for the t4 instances.
| rafaelturk wrote:
| We did is and is amazing! All the claims are true and worth it.
| If your stack is Linux Based you can be up and running within
| hours: Our stack is based on NodeJS, PostgreSQL, Nginx, Redis,
| MongoDB, MySQL
| booi wrote:
| The author makes it pretty clear this isn't a comparison of ARM
| vs. x86 but with the specs being nearly identical, I'm finding it
| very hard not to draw that conclusion. The difference is even
| larger when you factor in the cost difference.
|
| Are there other factors that could explain the large performance
| gap?
| hrez wrote:
| > the specs being nearly identical
|
| graviton2 are real cores while amd/intel is SMT vCPU's. So 2x
| real cores difference.
| STRML wrote:
| Sure, but it's also 20% cheaper to get the ARM setup, so I
| don't think it's fair to discriminate this way. In the end
| what matters is what I can buy, and ARM both offers more
| cores per socket and per dollar.
| llampx wrote:
| Possibly once AWS has gotten enough people switching to
| Graviton CPUs, they would start raising the cost.
| teej wrote:
| "Would" is a bold word choice given that AWS hasn't ever
| raised prices. Could, can, might - sure.
| greatpatton wrote:
| The cost here is an artificial variable as it completely
| under the control of AWS. They can decide to sell them very
| cheap to lock people on AWS.
| vorpalhex wrote:
| Yes but porting to other ARM nodes isn't difficult, and
| if you're already using AWS you're comfortable with a
| fair bit of lock-in already.
| chrischen wrote:
| I think what they mean is that there are enough non-CPU
| differences that you can't make this an accurate comparison.
| That being said at the end of the day the ARM instances are
| cheaper and better performing--whatever the reason may be.
| random5634 wrote:
| But the non CPU differences (compiler / linker / OS
| optimizations), number of drives etc - all seem to favor x86?
| wmf wrote:
| The SSD is clearly different. Are there other differences, or
| are people just assuming?
| random5634 wrote:
| Cost is a key factor. It should be trx/$. That really makes
| clear the ARM advantage here.
|
| Additionally the ARM version only had one disk vs two for x86.
|
| I also feel like there is more headroom for optimization now
| that ARM is more visible as a server class target in the non-
| postgresql toolchains.
| Thaxll wrote:
| It's a wrong measurement because not all workload can be
| "shardable". If your workload is bound to a single instance
| it does not really matter if it's a bit cheaper.
|
| Not every workload are behind a loadblancer, so single core /
| MT / single instance performance can be important.
___________________________________________________________________
(page generated 2021-01-22 23:00 UTC)