Hacker News Reader

Comment by bob1029 | Hacker News Reader

> Modern CPUs and ram are obscenely, incomprehensibly fast. With the exception of a few very specific tasks, you should never be waiting for a modern computer to do anything.

I really wish we could drive this point home for everyone. The amount of work you can get out of 1 x86 core is insane if you know how to feed it properly. The upper bound is somewhere around 500 million transactions per second per core. I have personally built systems that can achieve somewhere around 14 million per second.

If you can reliably handle the entire serialized workload on a single thread you start to retool for the idea that you can fit the entire business in 1 box.

Being able to run everything out of a single computer is an incredible virtue, not some curse that must be cast to the clouds.

View on HN

> Being able to run everything out of a single computer is an incredible virtue, not some curse that must be cast to the clouds.

Isn't the problem then: what happens when take computer goes down? I'm also on the side of "know your hardware", but the topic of resilience is a different one. Also, perhaps you didn't mean "single computer" in the literal way: it's not incompatible with avoid the cloud, though.

I did mean single computer in terms of 1 active primary machine at any given time.

Negotiate the advantages of this architecture with the business. For the systems I've built, synchronous log replication is a natural extension of the performance abstraction, and provides fairly robust protection when some manual intervention is allowed.

A good thing with "single computer" is that you have less complexity going into it so failures will be less frequent. For a lot of cases, that will be enough. It's also easier to build a resilient system starting from a single machine than from a cluster: less components to replicate to ensure they're redundant.

Something I've been telling customers for years is: I would rather have a standalone SQL Server Standard Edition instance on VMware than an Enterprise Edition cluster on anything.

Simple means that there's less things to break. This isn't just academic. My experience with clusters is that the clustering itself causes more problems than it solves.

(Don't think this is somehow isolated to Windows. ZooKeeper will refuse to start after a power outage for no discernible reason. Etc...)

> My experience with clusters is that the clustering itself causes more problems than it solves.

There's also a whole slew of failure modes that are capable of bringing down entire clusters if a single machine misbehaves. Usually to do with situations where the nodes are reachable, but some resource (I/O, latency, bandwidth) is uncharacteristically slow on one of the machines. I'm yet to encounter a distributed system that handles that situation well

Some people see small twin engine airplanes as safer than single engine. Single point of failure and all that.

The problem is that the two engines of an airplane aren’t independent of each other in the factors that threaten an engine. Same pilot, same fuel. Separate mechanical parts, but that’s a minority of issues.

Most engine-outs in small airplanes are caused by running out of fuel. Your two engines don’t help you there. If anything it’s more likely because of mismanaging the complex fuel system.

The most common phase for loss of an engine is on take off (misfueled, mechanical issue). This is what your comment reminded me of. With two engines, you’re more likely to have a mechanical issue on take off. While it’s generally theoretically survivable, handling one-sided power loss on takeoff requires a quick and counterintuitive response. That requires consistent training, more than most pilots do.

In a small, recreational twin, the most common outcome for an engine misbehaving on take off is it rolls the airplane, taking down the whole cluster.

I can’t echo this enough. At work our DevOps folks started out of the gate with a Postgres cluster (hosted in our K8s infrastructure) and it’s been a nightmare. Luckily we’re still in development mode and haven’t moved any customers to our new architecture. Complexity kills and most of the time YAGNI.

Well, you either fail the tasks, batch them, or alter them all into another computer. What you choose depends on what problem you are solving.

I built a production grade cluster for fun. It’s only three nodes… without anything installed on my 40 core cluster, except k8s and longhorn, it’s idling at 30% cpu usage. When I started up a managed cluster on Azure, I was throwing hundreds of euros at their logging storage just idling, so I noped to bare metal.

This mirrors my experience with K8s, though one can suggest that the software running on the cluster also played a part in it.

Have you looked into K3s or other lightweight distros of Kubernetes, though? https://k3s.io/

That's what i turned to when i needed to learn the Kubernetes API and explore running clusters, but didn't like my small VPSes (~4 GB of RAM) failing to launch anything because of the frankly insane resource usage of full K8s clusters.

We do need to account what is required and what is achievable for each use case.

We run an ERP system with >250k self-service users on a single beefy database. There's redundancy in web servers and app servers and proxy servers and whatnot. But in 5+ years and a LOOOOOOT of all kinds of issues -- it's never been that single big LPAR with single big RDBMS that was the issue. And we're not even on a mainframe. And it's not because we got lucky - some single-computer/LPAR/RDBMS stacks simply give us as many 9's as we need for our use-case.

(webservers on other hand - they feel like child's toys. I don't understand how these leaky errory cachy things survive... YOU HAVE ONE JOB! And you're not very good at it :P )

> The upper bound is somewhere around 500 million transactions per second per core.

What’s the definition of transaction here? That’s a transaction for every ~6 (peak ~10) clock cycles.

https://www.agner.org/optimize/instruction_tables.pdf

Transaction in this context being "Place order", "Cancel order", "Update user settings", etc.

We need to remember there isn't a 1:1 relationship between instruction/clock rate and the number of actual instructions that are retired per unit time. Pipelining and ILP allow for speedups that range anywhere from 1-100x depending on the specific flavor of application.

Most applications are IO bound, not CPU bound. So wasted cycles aren't always that big of a deal.

While this is most certainly true, I'm willing to bet the ratio between them has dropped substantially in recent years.

Most applications do far more IO than what is necessary for the task.

Anyway with a modern SSD I don't think you are right. My disk can do something like 3 GB/s and 100k random accesses per second. At that rate most desktop programs should have the binary and all dependencies loaded to memory in approximately 0.1s. That seemingly doesn't stop a lot of them from taking several seconds to boot. Likewise games, despite usually consuming less than 10 GB of video and main memory combined, can take much longer than 3.3s to load.

Though that includes possibly decompression, parsing, and more importantly loading data to the GPU and even compiling shaders.

Decompression is fast if you do it right (using anything from the Oodle pack is a good first step towards doing it right).

Hopefully a game doesn't need to parse a whole lot of things, however stuff needs to appear in memory, it can be stored that way on disk, possibly compressed with aforementioned fast compression libraries.

There is nothing special about loading data onto the graphics card, if you know what you are doing it is just copying data, and no point on the path is slower than disk.

I know there are games that somehow rely on thousands of shaders. Like most games you can just not do that, or you can store the compiled shaders so that the compilation only needs to be done on first run.

It's not a big deal if you're only running one thing on the computer. The wasted cycles could have been used by a different process to do something else. Multiply this mindset by many services and applications and suddenly the computer is slow when it doesn't have to be.

What do you mean by „most applications“ and what is the IO you talk about? Do you have data to backup your claim.

Most applications are not intrinsically I/O bound, it is only an artifact of the scale of wastefulness and inefficiency in how they use I/O. Even databases are no longer I/O bound except at the extremes -- memory bandwidth is likely a bigger bottleneck if the I/O is handled competently.

Software being "I/O bound" stopped being a legitimate excuse for the vast majority of applications many years ago. Hardware and software has moved on.

> Even databases are no longer I/O bound except at the extremes -- memory bandwidth is likely a bigger bottleneck if the I/O is handled competently.

> Software being "I/O bound" stopped being a legitimate excuse for the vast majority of applications many years ago. Hardware and software has moved on.

You know, i'm not sure about that.

You can write really performant code, but oftentimes in our world that's increasingly infected by SaaS solutions, you'll be bottlenecked by network calls, be it to an external service or a DB instance.

Sure, your DB driver might be really performant and the actual progress made in the last decades on the DB engines has been amazing, but you can't beat the speed of light.

And, since many still choose external DBs when something like a local SQLite DB would suffice (sometimes a form of cargo culting, sometimes choosing a particular risk management profile/failure mode with multiple nodes), that cannot exactly be ignored anyways.

As you say, it could be done simpler. What we have is a manifestation of wastefulness.

> 500 million transactions per second per core.

An instruction is not a transaction. Commodity x86/x64 systems do not implement transactional memory or any model of computation that could be reasonably described as transactional as far as I'm aware.

I'm not referring to individual instructions. I'm talking about actual useful changes to business state.

500 million instructions per second can be achieved on a pentium pro from 1995, modern CPUs run many orders of magnitude faster than that.

Reply on news.ycombinator.com