Live data from Hacker News

Ask HN: Running production server on M1 mini?

news.ycombinator.com

51–60 of 65 posts

Re: Ask HN: Running production server on M1 mini?

#51
post #3

don’t ask me how _You_ should be asking you how - there are lots of reasons why this could be happening and knowing which one is important if you're changing stuff. Based on a "highly parallelizable" application performing better on 8 cores than 32, I'd guess you're running out of something else: memory or disk bandwidth.

It does not consume much memory but do lots of allocations/deallocations. No disc operations whatsoever.

M1 has a larger L1 cache, but smaller L3 cache.

It could very well be that your application is hitting a memory pattern that favors larger L1 cache, while the huge L3 cache of EPYC is not useful.

------

If you really wanted to know, you should learn how to use hardware performance counters and check out the instructions-per-clock. If you're around 1 or 2 instructions per clock tick, then you're CPU-bound.

If you're less than that, like 0.1 instructions per clock (ie: 10 clocks per instruction), then you're Cache and/or RAM-bound.

-----

From there, you continue your exploration. You count up L1 cache hits, L2 cache hits, L3 cache hits and cache-misses. IIRC, there are some performance counters that even get into the inter-thread communications (but I forget which ones off the top of my head). Assuming you were cache/ram bound of course (if you were CPU-bound, then check your execution unit utilization instead).

EPYC unfortunately doesn't have very accurate default performance counters, and I'd bet that no one really knows how to use M1 performance counters yet either.

While the default PMC counters of AMD/EPYC are inaccurate (but easy to understand), AMD has a second set of hard-to-understand, but very accurate profiling counters called IBS Profiling: https://www.codeproject.com/Articles/1264851/IBS-Profiling-w...

Still, having that information ought to give you a better idea of "why" your code performs the way it does. You may have to activate IBS-profiling inside of your BIOS before these IBS-profiling tools work.

By default, AMD only has the default performance counters available. So you may have a bit of a struggle juggling the BIOS + profiler to get things working just right, and then you'll absolutely struggle at understanding what the hell you're even looking at once all the data is in.

Re: Ask HN: Running production server on M1 mini?

#52

Earlier quoted context omitted.

What was the M1 % relative to your Epyc?

Roughly 10% faster

Have you investigated memory constraints?

Ryzen is 2 channels; Epyc is 4-8 (depending on CPU). M1 has that stupidly fast/wide setup.

If your Epyc is one of the 4 channel optimized SKUs or is only running in 4 channel mode, you would get pretty close to the quoted ratios on a memory bandwidth test.

Correlation, not causation, but worth looking into.

Re: Ask HN: Running production server on M1 mini?

#53

Earlier quoted context omitted.

> No currently offered M1 Mini has redundant fail-over power or storage. It's kind of funny, but an M1 MacBook does. In fact it comes with a solid >12 hour UPS built-in.

So does a data center. Neither one has a redundant PSU.

A MacBook can actually have multiple power supplies plugged in at once and will use the more powerful one. I bet having two of the same wattage would work fine. It also works with the new MacBook Pros with MagSafe.

In fact, if you plug the type-C end of MagSafe cable into the MacBook, it will "charge" itself. USB-PD is pretty great.

It's too bad the Mac mini can't be powered over USB-C though.

Re: Ask HN: Running production server on M1 mini?

#54
post #47

No personal experience other than a slightly different experience running production services (involving money!) on another box without ECC DRAM (to save money!) and experiencing random permission flags flips and actual balance/amount flips. Only a small handful over many years, but it does happen, and when it matters, it REALLY matters. My advice is to always use ECC DRAM in production unless you're serving cat phot…

Yes this is one concern. Are you sure it was a result of using non ECC mem and how did you find out it was because of that?

We could never be absolutely sure, due to the true Heisenbug nature of the behavior, but after tons of code audits and the observation after reverse proxy traffic analysis that it only occurred on processing by the non-ECC hosts, and never on the ECC hosts, that it was the most likely culprit.

The fact that the errors were single bit errors also strongly pointed in that direction.

Re: Ask HN: Running production server on M1 mini?

#55
>our M1 is actually performing better performance wise

I did performance analysis work for a long span of my career. While I'm reading between the lines of what you wrote, my first question is - what do you mean by performing better? As in, is it somehow able to process more of these tasks over a given timeframe? If so, I'd want to understand more about the workloads you are running to make sure it's a proper comparison.

There's a whole lot more questions we need to answer here to understand the results you are seeing before we can have any kind of discussion of whether M1s would be "better."

Re: Ask HN: Running production server on M1 mini?

#56

can you describe the program? just broad strokes about language, framework, what kind of traffic it's receiving?

It’s written in Rust and uses Rayon to a big extent. It’s receiving data to crunch maybe once every 5 minutes

the msg from dragontamer to set up a profiler seems like one approach to diagnose this

and also from joshdev to try aws graviton, which is also arm based but potentially more suited for cloud hosting than an m1

if you figure this out, definitely write it up -- very cool tech blog topic, most people never get to debug cpu architecture firsthand

Re: Ask HN: Running production server on M1 mini?

#58
post #3

don’t ask me how _You_ should be asking you how - there are lots of reasons why this could be happening and knowing which one is important if you're changing stuff. Based on a "highly parallelizable" application performing better on 8 cores than 32, I'd guess you're running out of something else: memory or disk bandwidth.

+1. They should start profiling their application. If its running on alpine linux e.g. the default memory allocator is extremely bad and would degrade performance - but it could also be tons of other things. Taking random actions without understanding what the current bottleneck is will never be great long term.

Re: Ask HN: Running production server on M1 mini?

#60

Earlier quoted context omitted.

Roughly 10% faster

Have you investigated memory constraints? Ryzen is 2 channels; Epyc is 4-8 (depending on CPU). M1 has that stupidly fast/wide setup. If your Epyc is one of the 4 channel optimized SKUs or is only running in 4 channel mode, you would get pretty close to the quoted ratios on a memory bandwidth test. Correlation, not causation, but worth looking into.

Also check Node per Socket (NPS) settings on EPYC
Post reply on HN