27 ms·
The Google SREs mentioned this in their book; the Chubby locking service had uptime that was so high that folks started to neglect making their own services res
by ksmith14 8y ago
The Google SREs mentioned this in their book; the Chubby locking service had uptime that was so high that folks started to neglect making their own services resilient to Chubby failures: https://landing.google.com/sre/book/chapters/service-level-objectives.html#xref_risk-management_global-chubby-planned-outage https://landing.google.com/sre/book/chapters/service-level-o...
- mav3rick 8y agoStill that's bad design on the clients' part. E.g. - Just because malloc "never" fails doesn't mean it can't fail :) so better error check for it.
- Filligree 8y agoDoesn't matter. Engineering around human failure is part of the profession.
- smcameron 8y agoFailure of malloc() might be a bad example to pick because on linux, by default, most distros overcommit, so malloc won't fail, generally. Instead, malloc will succeed allocating the address space just fine, but the RAM will get allocated upon first use, meaning that even though malloc gave you a supposedly valid pointer rather than NULL, actually using that pointer will crash your program.
- tannhaeuser 8y agoIs there a way to fix this/switch it off? I never got the rationale for this behaviour.
- zorked 8y agoThere's a sysctl: vm.overcommit_memory=2 What most people don't realize is that you will get more OOMs if you disable overcommit.
- mav3rick 8y agoOther distros may have this differently and return NULL. It's not portable and also just bad to not check for it.
- robax 8y ago+1 for this book. As a junior DevOps engineer this book has been super helpful.