4 ms·
For us software developers, it seems like the shipping industry has the container equivalent of a memory leak (a "container leak" if you will). Then the stackin
by SkeuomorphicBee 5y ago
For us software developers, it seems like the shipping industry has the container equivalent of a memory leak (a "container leak" if you will). Then the stacking rule change is the equivalent of simply adding more memory to the system, it doesn't fix the problem, but it buys you some more time of normal system operation before the next out-of-memory crash. Hopefully they use this time they bought to work on an actual solution to the original leak.
- bluGill 5y agoNo, it isn't a leak as the containers are empty but not garbage. It is very common to allocate extra memory that isn't used - in garbage collected languages you often need to fight the garbage collector for maximum performance in specific ways - which means you will have empty objects just waiting to be filled. You will get around to them eventually, but for now they are just taking up memory. If you allocate more of these objects than you have physical ram you will start swapping - but there is no leak, you will eventually either use them, or destroy them. If you don't worth in latency senstive applications you might not have encountered a situation where you need to apply the above tricks.
- tuatoru 5y agoLol! Continuing this analogy, what has happened is that the swap space for containers has filled, and it now has a form of compression applied to it, so that five containers can now be stored in the space where two could be beforehand. (Edit: let's hope the swap space doesn't become encrypted.) I wonder when the out-of-memory-killer process will start up? What would it look like--just not shipping anything to the US for a few months?
- morelisp 5y agoIf you want to phrase it in programming terms, there's a pretty obvious comparison to semaphores and deadlocks. We've deadlocked. As a workaround we've increased a bunch of our semaphore limits. But we also had those limits for a reason (various balances of safety, efficiency, and available amount of other ancillary resources). Maybe now we'll run out of some other resource, or hit contention somewhere else - we don't really know, the system is big and hasn't been operated in this state before. And on top of that, we didn't solve the fundamental deadlock - if the underlying conditions persist, there's hard limits to how often we can do this before we deadlock permanently.