3 ms·
When your program OOMs, you have three options: - You can reduce the program's memory usage, or increase the program's / system's alloted memory. But there's u
by morelisp 5y ago
When your program OOMs, you have three options:
- You can reduce the program's memory usage, or increase the program's / system's alloted memory. But there's usually some hard limit to this - if you've got 100GB of data, you've got 100GB if data, and if you've got a non-distributed problem you'll eventually run out of RAM slots. Plus you usually just get induced demand when a customer shows up the next day with 200GB data.
- You can make the program handle the too-large-data case better. This requires deeper systemic changes usually across multiple components (the program, your monitoring and error reporting, upstream and downstream integrations). But this also tends to have knock-on improvements across the system. And a lot of times it's cheaper than the first option when you compare total rather than marginal cost.
Or to be more direct: Why fuss over 131x10 feet and not the fact your only recovery plan is one excavator and a handful of tugboats?
- ignoramous 5y ago> Or to be more direct: Why fuss over 131x10 feet and not the fact your only recovery plan is one excavator and a handful of tugboats? One should identify both corrective measures and preventive measures in equal measure.
- morelisp 5y agoAs long as people are heavily incentivized to build boats to exactly the size of the canal (i.e. as long as international shipping exists) the measure isn't actually preventative.
- aliceryhl 5y agoRegarding this, see this other comment: https://news.ycombinator.com/item?id=27173290 https://news.ycombinator.com/item?id=27173290
- dale_glass 5y agoIt's kind of a tricky problem. If something needs such help once in a decade, how do you deal with it? It may make no economical sense to build infrastructure to deal with a very rare problem, when it may be cheaper long term just to laboriously dig the ship out, even if it looks embarrassing. Also it seems like a win-win approach: harder for ships to get stuck, and room for more traffic.
- masklinn 5y ago> When your program OOMs, you have three options: The issue with your analogy is that here the "program" did not OOM as part of normal operations, instead it OOM'd because of a rare condition you can't really avoid (even calling it a bug is debatable, as a bug implies misbehaviour in the canal). In that case, increasing your safety buffer so you can recover before swapping to death or the OOM killer -9-ing programs left and right is a good idea. > - You can make the program handle the too-large-data case better. This requires deeper systemic changes usually across multiple components (the program, your monitoring and error reporting, upstream and downstream integrations). But this also tends to have knock-on improvements across the system. How would you make "the program" handle "the too-large case better" exactly? As in, how would the canal handle a ship getting stuck sideways after having lost propulsion save by being wider than the ship can be long? > And a lot of times it's cheaper than the first option when you compare total rather than marginal cost. We're talking about a 200km canal. > Why fuss over 131x10 feet and not the fact your only recovery plan is one excavator and a handful of tugboats? Maybe they're working on both but increasing the canal width to provide more buffer in case of rare issues is a much more complicated and thus interesting thing, and thus gets more visibility?
- rswail 5y agoOr duplicate that section of the canal, like the remainder.