thanks, bill. i killed an old filesystem. also forgot about
arc_meta_limit. kicked it up to 4gb from 2gb. things are back to
On Thu, Dec 15, 2011 at 1:06 PM, Bill Sommerfeld
> On 12/15/11 09:35, milosz wrote:
>> hi all,
>> suddenly ran into a very odd issue with a 151a server used primarily
>> for cifs... out of (seemingly) nowhere, writes are incredibly slow,
>> often<10kb/s. this is what zpool iostat 1 looks like when i copy a
>> big file:
>> storepool 13.4T 1.07T 57 0 6.13M 0
>> storepool 13.4T 1.07T 216 91 740K 5.58M
>> any ideas? pretty stumped.
> Behavior I've observed with multiple pools is that you will sometimes hit a
> performance wall when the pool gets too full; the system spends lots of time
> reading in metaslab metadata looking for a place to put newly-allocated
> blocks. If you're in this mode, kernel profiling will show a lot of time
> spent in metaslab-related code.
> Exactly where you hit the wall seems to depend on the history of what went
> into the pool; I've seen the problem kick in with only 69%-70% usage in one
> pool that was used primarily for solaris development.
> The workaround turned out to be simple: delete stuff you don't need to keep.
> Once there was enough free space, write performance returned to normal.
> There are a few metaslab-related tunables that can be tweaked as well.
> - Bill
zfs-discuss mailing list