On 23.04.2011, at 16:10, Edward Ned Harvey wrote: >> From: Toomas Soome [mailto:toomas.so...@mls.ee] >> >> well, do a bit math. if ima correct, with 320B DTT the 1.75GB of ram can > fit >> 5.8M entries, 1TB of data, assuming 128k recordsize would produce 8M >> entries.... thats with default metadata limit. unless i did my > calculations >> wrong, that will explain the slowdown. > > Not sure where you're getting those numbers, but rule of thumb is to add > 1-3G of ram for every 1T of unique dedup data. > > http://hub.opensolaris.org/bin/view/Community+Group+zfs/dedup
1. one DTT entry would use either 250B or 320B of ram - if you google around, there are hints its 250B, but some mail in this list was referencing its 320B. so, lets be conservative and use 320B as reference value. 2. the refault recordsize is 128k, meaning, if you are lucky, you can have pool size / 128k to get the count of DTT entries needed. note that not all data is stored by 128k blocks (esp true if you have just generic file server), but if you have backup target (which is basically only good target for dedupe), you may be lucky. note that smaller recordsize will produce more DTT entries. 3. so the amount of the space needed to keep DTT is 320B * DTT entries. 4. DTT is metadata for arc or l2arc. the metadata limit is arc_c_max / 4 (read the source!). meaning, if you add 4GB of ram for arc, you will get 1GB for metadata (actually a bit less, because arc_max is RAM - 1GB - hard limit). 5. note that all those calculations dont count in the "normal" metadata. 6. note that l2arc would change those numbers as well, because blocks in l2arc need pointers in ram. 7. note you can (and probably should) rise the arc metadata limit. toomas _______________________________________________ OpenIndiana-discuss mailing list OpenIndiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss
