On 1.08.19 г. 5:17 ч., Dave Chinner wrote: > From: Dave Chinner <dchinner@xxxxxxxxxx> > > The current CIL size aggregation limit is 1/8th the log size. This > means for large logs we might be aggregating at least 250MB of dirty objects > in memory before the CIL is flushed to the journal. With CIL shadow > buffers sitting around, this means the CIL is often consuming >500MB > of temporary memory that is all allocated under GFP_NOFS conditions. > > FLushing the CIL can take some time to do if there is other IO > ongoing, and can introduce substantial log force latency by itself. > It also pins the memory until the objects are in the AIL and can be > written back and reclaimed by shrinkers. Hence this threshold also > tends to determine the minimum amount of memory XFS can operate in > under heavy modification without triggering the OOM killer. > > Modify the CIL space limit to prevent such huge amounts of pinned > metadata from aggregating. We can 2MB of log IO in flight at once, There is a word missing between 'can' and '2MB' > so limit aggregation to 8x this size (arbitrary). This has some > impact on performance (5-10% decrease on 16-way fsmark) and > increases the amount of log traffic (~50% on same workload) but it > is necessary to prevent rampant OOM killing under iworkloads that > modify large amounts of metadata under heavy memory pressure. > > This was found via trace analysis or AIL behaviour. e.g. insertion s/or/of/ > from a single CIL flush: <snip>
