4 ms·

> second, by placing computers under constant demand, they were more likely to fail Really? In what sense? Hardware fails or what? The complexity usually bring

by jve 5y ago

> second, by placing computers under constant demand, they were more likely to fail Really? In what sense? Hardware fails or what? The complexity usually brings everything down. Anyway, looking forward to cockroachdb, it seems it solves some high-availability / multi-site problems.

notacoward 4y ago
I think what the authors are getting at is that many failure conditions are more likely to manifest under load. This includes various kinds of resource exhaustion, including those induced by leaks. It also includes things like timeouts due to long queues, and even race conditions. The higher the load, or the longer it's sustained, the more likely it becomes that such bugs will manifest. In every such system I've seen, from very early days of the internet or old-school HA to modern multi-thousand-machine clusters, there have been bugs that only showed up under heavy and/or sustained load. Both Erlang's supervisor trees and Recovery Oriented Computing (Berkeley/Stanford) are based on the observation that such failures will always be with us, and have influenced many subsequent systems - arguably including CockroachDB.
- marcosdumay 4y ago
  Heat caused failures also increase with load, as does electromigration, disk stress, power failures... The GP has a very digital model of computers. It's not really useful for predicting failure.
zamadatix 4y ago
One concrete example involving DBs is the PostgreSQL TXID wraparound. It's basically 32 bit counter where if things go wrong or were built wrong it just keeps going up until it becomes a problem. If you're only doing <=1 request per second this won't ever be a problem since even if you ran it your whole life without freezing any old records it wouldn't approach max value. On the other hand if it's under a constant 1000 request per second load it can be the source of problems in about a month. You could argue to just call the TXID "complexity" but that'd come with a wide enough definition of what complexity is that it just becomes a replacement for saying "buggy code" which isn't very useful. Most leave complexity as being more like "grossly overengineered" to leave room to avoid that.

by jve 5y ago

notacoward 4y ago

I think what the authors are getting at is that many failure conditions are more likely to manifest under load. This includes various kinds of resource exhaustion, including those induced by leaks. It also includes things like timeouts due to long queues, and even race conditions. The higher the load, or the longer it's sustained, the more likely it becomes that such bugs will manifest. In every such system I've seen, from very early days of the internet or old-school HA to modern multi-thousand-machine clusters, there have been bugs that only showed up under heavy and/or sustained load. Both Erlang's supervisor trees and Recovery Oriented Computing (Berkeley/Stanford) are based on the observation that such failures will always be with us, and have influenced many subsequent systems - arguably including CockroachDB.

marcosdumay 4y ago
Heat caused failures also increase with load, as does electromigration, disk stress, power failures... The GP has a very digital model of computers. It's not really useful for predicting failure.

zamadatix 4y ago

One concrete example involving DBs is the PostgreSQL TXID wraparound. It's basically 32 bit counter where if things go wrong or were built wrong it just keeps going up until it becomes a problem. If you're only doing <=1 request per second this won't ever be a problem since even if you ran it your whole life without freezing any old records it wouldn't approach max value. On the other hand if it's under a constant 1000 request per second load it can be the source of problems in about a month. You could argue to just call the TXID "complexity" but that'd come with a wide enough definition of what complexity is that it just becomes a replacement for saying "buggy code" which isn't very useful. Most leave complexity as being more like "grossly overengineered" to leave room to avoid that.