Hi Robert, We've got the default ncsize. I didn't see any advantage to increasing it outside of NFS serving...which this server is not. For speed the X4500 is showing to be a killer MySQL platform. Between the blazing fast procs and the sheer number of spindles, its perfromance is tremendous. If MySQL cluster had full disk-based support, scale-out with X4500s a-la Greenplum would be terrific solution.
At this point, the ZFS memory gobbling is the main roadblock to being a good database platform. Regarding the paging activity, we too saw tremendous paging of up to 24% of the X4500s CPU being used for that with the default arc_max. After changing it to 4GB, we haven't seen anything much over 5-10%. Best Regards, Jason On 1/10/07, Robert Milkowski <[EMAIL PROTECTED]> wrote:
Hello Jason, Thursday, January 11, 2007, 12:36:46 AM, you wrote: JJWW> Hi Robert, JJWW> Thank you! Holy mackerel! That's a lot of memory. With that type of a JJWW> calculation my 4GB arc_max setting is still in the danger zone on a JJWW> Thumper. I wonder if any of the ZFS developers could shed some light JJWW> on the calculation? JJWW> That kind of memory loss makes ZFS almost unusable for a database system. If you leave ncsize with default value then I belive it won't consume that much memory. JJWW> I agree that a page cache similar to UFS would be much better. Linux JJWW> works similarly to free pages, and it has been effective enough in the JJWW> past. Though I'm equally unhappy about Linux's tendency to grab every JJWW> bit of free RAM available for filesystem caching, and then cause JJWW> massive memory thrashing as it frees it for applications. Page cache won't be better - just better memory control for ZFS caches is strongly desired. Unfortunately from time to time ZFS makes servers to page enormously :( -- Best regards, Robert mailto:[EMAIL PROTECTED] http://milek.blogspot.com
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
