On Wed, Oct 22, 2008 at 11:05:09PM +0200, Kees Nuyt wrote: > [Default] On Tue, 21 Oct 2008 15:43:08 -0400, Bill Sommerfeld > <[EMAIL PROTECTED]> wrote: > > >On Mon, 2008-10-20 at 16:57 -0500, Nicolas Williams wrote: > >> > >> I've a report that the mismatch between SQLite3's default block size > >> and ZFS' causes some performance problems for Thunderbird users. > > > > I was seeing a severe performance problem with sqlite3 databases > > as used by evolution (not thunderbird). > > > > It appears that reformatting the evolution databases to a 32KB database > > page size and setting zfs's record size to a matching 32KB has done > > wonders for evolution performance to a ZFS home directory. > > Just a remark: > Increasing the SQLite page_size while keeping the same > [default_]cache_size will effectively increase the amount of memory > allocated to the SQLite cache, because the SQLite cache_size is > expressed in pages. > IMHO, for a fair performance comparison, one should half the > cache_size when the page_size is doubled.
I'm not sure that I agree. While the cache gets larger if you increase the page size, the cache nonetheless caches the same number of integral pages. Each miss requires reading a whole page, and each addition to the cache, when full, requires evicting another. Going from 1KB pages to 32KB pages would require going from cache_size=2000 to cache_size=62 by your logic, but 64 is a rather small number -- sure there will be so many evictions for a sufficiently large DB (at least 2MB) that you'll be thrashing. Conversely, 64MB of cache is a lot for most of the apps we're talking about, so perhaps I should leave the max default page size at 8KB. Nico -- _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
