I would expect that after filling an aggregate your performance deficit would go away one you frees up the blocks unless you happen to free up blocks that happened to be a huge hot spot.
Think of it this way. The reasons for the slowdown when the aggregate is near full is because wafl does not have enough contiguous free space to write a chain of contiguous blocks to each disk. It instead has to hold back the CP, read the closest thing it can find to a contiguous group of chains onto memory fill in the holes with what it wanted to write , and then put the tetris back down to disks. These are know as cp_reads and unless write I/o is very low will cause back to back Cp's which translates to high write latency and angry users. ________________________________________ From: toasters-bounces@teaparty.net [toasters-bounces@teaparty.net] on behalf of Michael Bergman [michael.bergman@ericsson.com] Sent: Thursday, November 05, 2015 6:06 PM To: Toasters Subject: Re: Completely filling and aggregate
Jeffrey Steiner wrote:
The rule I usually use is this: [...]
You'll probably start seeing slowdowns as approach 95%.
That threshold depends on the workload -- among a bunch of other things the level of random overwrites -- if you're using dedup or not, etc. Baiscally: what is the workload doing to your free space in the Aggr, and can free_space_realloc [on | no_redirect] hold it nice and clean? If not...
More often than not you'll see slowdown, especially for W (higher latency, and/or spikes) long before you reach 95%. More like 85+ somewhere, I'd say. Sure, I have very heavy nasty NFSv3 workload here, most ppl prob will never see such stuff, but >90% here is a really really bad idea
Need to aim for having it around 80% max. Trying to do a reallocate -A with less than that avail in an Aggr isn't pleasant trust me
/M
_______________________________________________ Toasters mailing list Toasters@teaparty.net http://www.teaparty.net/mailman/listinfo/toasters