> Why not go to 128-256 GBytes of RAM? It isn't that > expensive and would > significantly help give you a "big performance boost" > ;-)
Would be nice, but it not that much inexpensive since we'd have to move up a class in server choise, and besides the extra memory cost, also brings some more money with it. > The database transaction log should be relatively > small, so I would > look for two LUNs (disks), mirrored. Similarly, the > ZIL should be > relatively small -- two LUNs (disks), mirrored. You > will want ZFS to > manage the redundancy here, so think about mirroring > at the > ZFS level. The actual size needed will be based on > the transaction > load which causes writes. For ZIL sizing, we like to > see something > like 20 seconds worth of write workload. In most > cases, this will > fit into the write cache of a decent array, so you > may not have to > burn an actual pair of disks in the backing store. > But since I don't > now the array your using, it will be difficult to be > specific. Oka, so if the array cache is large enough, there is no actual need for a seperate ZIL disk. Another consideration could be the use of SSD's for all of the stuff. You'll only need a few of these to have by far beter IO performance than the 16 SAS disks could ever do. Also, you'd probably not need a ZIL disk, nor a disk for the transaction log. It will cost about the same, but will probably give better performance This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
