Comment by travisjungroth | Hacker News Reader

Comment by travisjungroth | Hacker News Reader

Parent Full thread

Fully departing from spoon theory, but sticking with money and motorcycles, this story was told to me by a friend of mine. This was a few decades ago and he was into racing Ducatis.

The wise old man at the track was explaining how to go fast. The people in the garage that night didn’t seem to be getting it, so everyone got in the back of the Ford van they used for parts and the old man drove.

“You have a dollar to spend. You can spend it on acceleration, braking, or turning. You need to be spending the whole dollar all the time.”

He was coming into a turn faster than any Ford engineer would have expected, gas to the floor. “I’m still spending the dollar on the gas.” He switched to the brakes, slamming them without skidding. The guys slid to the front of the van. “Now the brakes, I’m spending the whole thing. And then to turning.” The guys hit the side of the van.

This continued on, him ranting about dollars while driving around the track. My friend timed the lap and it was embarrassingly close to what they did on their Ducatis. That old man speed.

You should always be either at the edge of your traction circle or at the full limit of one of your controls. Anything less is wasting time.

This notion of limits and edge reminds me of Hunter Thompson's musings on "The Line" in his piece about the Hell's Angels. He argues (wildly paraphrasing) that the fundamental draw (and in some sense, the art) of motorcycles or extreme sports is in finding that edge or limit. The problem he identifies being that you cannot really know where it is without going over it, with all the consequences.

https://en.wikipedia.org/wiki/Hell%27s_Angels:_The_Strange_a...

I think he returns to the theme in "The Song of the Sausage Creature."

Myself, I can barely ride a simple bicycle more than about two hundred feet without somehow dislodging myself in a manner with roughly equal parts comedy and tragedy, but the way he wrote that and described the attraction of an edge where on one side laid a perfect moment-to-moment mastery of all of the physics in racing and the appeal of having absolutely nothing else matter at the moment because you simply haven't the space in your brain to do anything else ... and the other side, which involves multiple surgeries, rehab, and long phone calls with insurance companies, it was very appealing. "One of my finest addictions" indeed.

That's the theory. In practice, it's more complex and subtle:

- Not are limits are made equal. Some are okay to be approached from both sides, while others will make you crash very quickly. Racing is a lot about finding and feeling those limits, rather than just knowing that they exist and need to be applied.

- Changing gear, breaking, and applying gas all are physical actions that need some dexterity, to quickly switch between those within fractions of a second is sometimes infeasible. So racers end up just coasting for a short moment to avoid the high risk of a mistake for just a tiny gain.

- Throttle and breaks obviously can't always be fully applied depending on friction, or the danger of one of the wheels getting too much air.

- In a race there is a legit trade-off between lap times and tire wear. Losing too much material early-on will gain you some time initially, but make you lose more towards the end.

> In practice, it's more complex and subtle

If ever there were a statement more universally applicable, I've not encountered it. :)

Racing is, of course, about finishing the race (or maybe the season) first (along with all of additional considerations that implies), not just lapping fast.

It's similar to server apps. They should either have empty queue or max out a resource (CPU, disk bandwidth, network bandwidth).

Sorry, is this true? Last days I spent a lot of time going crazy because our apps are consuming 90% of memory on our instances and I feel bad/scary for that.

The principle is true and follows from the rule that no resource should be idle if there are requests that need it to be processed.

Memory, however is seldom the bottleneck. This is because most apps are not designed to queue requests if they don't fit in the available memory - they just allocate until they fail.

So, unless your apps are designed to queue requests in order to fit them into memory, this principle is probably not the explanation for the high memory usage.

At a minimum, you have to define max correctly. That’s not 100.00% of RAM bytes or CPU cycles and is probably under 25% of Ethernet networks for example.

Two questions you need to answer:

1. Is the app breaking or failing or not serving its purpose in any way? First find the problem, then look for the causes.

2. Let's say your app is using 29G of the memory in a 32GB instance. If you put it in a 64GB instance, will it use 29GB of that, 63GB of that, or does it continue to grow until it runs out of memory and restarts? The first case means you have correctly sized your instance. The second case means the app is good about using almost but not quite all the memory available. The third case is a problem.

The app is not breaking for now, but it will if we send more requests. The problem we are facing is that if we keep adding more instances (we are using Azure web app) the other instsancs also consume 80% (I thought the original memory consumption would be split equally on all instances).

So it seems it is the second case.

Reply on news.ycombinator.com