On Oct 22, 2012, at 6:52 AM, Chris Nagele <nag...@wildbit.com> wrote:
>> If after it decreases in size it stays there it might be similar to:
>> 7111576 arc shrinks in the absence of memory pressure
> After it dropped, it did build back up. Today is the first day that
> these servers are working under real production load and it is looking
> much better. arcstat is showing some nice numbers for arc, but l2 is
> still building.
> read hits miss hit% l2read l2hits l2miss l2hit% arcsz l2size
> 19K 17K 2.5K 87 2.5K 490 2.0K 19 148G 371G
> 41K 39K 2.3K 94 2.3K 184 2.1K 7 148G 371G
> 34K 34K 694 98 694 17 677 2 148G 371G
> 16K 15K 1.0K 93 1.0K 16 1.0K 1 148G 371G
> 39K 36K 2.3K 94 2.3K 20 2.3K 0 148G 371G
> 23K 22K 746 96 746 76 670 10 148G 371G
> 49K 47K 1.7K 96 1.7K 249 1.5K 14 148G 371G
> 23K 21K 1.4K 93 1.4K 38 1.4K 2 148G 371G
> My only guess is that the large zfs send / recv streams were affecting
> the cache when they started and finished.
There are other cases where data is evicted from the ARC, though I don't
have a complete list at my fingertips. For example, if a zvol is closed, then
the data for the zvol is evicted.
> Thanks for the responses and help.
> zfs-discuss mailing list
zfs-discuss mailing list