> From: Richard Elling [mailto:richard.ell...@gmail.com] > > > Worse yet, your arc consumption could be so large, that > > PROCESSES don't fit in ram anymore. In this case, your processes get > pushed > > out to swap space, which is really bad. > > This will not happen. The ARC will be asked to shrink when other memory > consumers demand memory. The lower bound of ARC size is c_min
Makes sense. Is c_min a constant? Suppose processes are consuming a lot of memory. Will c_min protect L2ARC entries in the ARC? At least on my systems, it seems that c_min is fixed at 10% of the total system memory. If c_min is sufficiently small, relative to the amount of ARC that would be necessary to index the L2ARC... Since every entry in L2ARC requires an entry in ARC, this seems to imply, that if process memory consumption is high, then both the ARC and L2ARC are effectively useless. Things sometimes get evicted from ARC completely, and sometimes they get evicted into L2ARC with only a reference still remaining in ARC. But if processes consume enough memory on the system so as to shrink the ARC to effectively nonexistent, then the L2ARC must also be nonexistent. > L2ARC is populated by a thread that watches the soon-to-be-evicted list. This seems to imply, if processes start consuming a lot of memory, the first thing to disappear is the ARC, and the second thing to disappear is the L2ARC (because the L2ARC references stored in ARC get evicted from ARC after other things in ARC) > AVL trees Good to know. Thanks. > > So the point is - Whenever you do a write, and the calculated DDT is not > > already in ARC/L2ARC, the system will actually perform several small reads > > looking for the DDT entry before it finally knows that the DDT entry > > actually exists. So the penalty of performing a write, with dedup enabled, > > and the relevant DDT entry not already in ARC/L2ARC is a very large > penalty. > > "very" is a relative term, Agreed. Here is what I was implying: Suppose you don't have enough ram to hold the complete DDT. And you perform a bunch of random writes (whether sync or async). Then you will suffer a lot of cache-misses searching for DDT entries, and the consequence will be ... For every little write that could potentially have only the disk penalty of one little write, instead has the disk penalty of several reads plus a write. So your random write performance is effectively several times slower than it could potentially have been, if only you had more ram. Reads are unaffected, except if there's random-write congestion hogging disk time. _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
