Re:Operating a large distributed system in a reliable way: p...
by learnfromstory on Wednesday July 17, 2019 @04:59PM
(#20463947)
Could you mention which FAANG so I can avoid applying or a job there? Large-scale software systems _must_ be designed to serve through local resource exhaustion. If you are paging on resource exhaustion of single host you are just paying the interest on your technical debt by drawing down your SREs' quality of life.
I stand by my beef with this article. The statement that "I've talked with engineers at Google [and concluded that a thing Google wouldn't tolerate is a must-have]" doesn't make sense. What I get from this article is you can talk with engineers at Google without learning anything.
Re:Operating a large distributed system in a reliable way: p...
by kevinsundar on Wednesday July 17, 2019 @05:08PM
(#20464032)
Im not at liberty right now to name my employer but our systems are definitely designed to serve through local resource exhaustion. But we aren't talking about cheap hosts here. We generally run high compute optimized or high memory optimized hosts depending on the use case and if these generally powerful hosts hit 100% CPU or full memory utiliziation theres usually more going on than something random or simple so its important to have someone check it out.
Re:Operating a large distributed system in a reliable way: p...
by packetslave on Wednesday July 17, 2019 @07:36PM
(#20465153)
A single host stuck at 100% CPU also has a nasty effect on your tail latency, in a system with wide fanout. If a request hits 100 backend systems, and 1 of them is slow, your 99th percentile latency is going to go in the toilet.
Re:Operating a large distributed system in a reliable way: p...
by learnfromstory on Wednesday July 17, 2019 @09:21PM
(#20465762)
Which is a good reason to hedge and replicate but NOT a reason to alert on high CPU usage of single computers.
Re:Operating a large distributed system in a reliable way: p...
by packetslave on Wednesday July 17, 2019 @10:42PM
(#20466229)
You definitely want to TRACK cpu usage on individual hosts, but, yeah, I would alert on service latency instead. Symptom, not cause.
For example: if you have a fleet of hosts handling jobs with retries, a bad job could end up being passed host to host killing each host / locking up each one as it gets passed along. And that could happen in minutes while replacing and deploying and bootstrapping a new host takes longer. So by the time your automated system detects, removes, and spins up a new host everything is on fire.