On Tue, Jul 1, 2008 at 8:10 AM, Mike Gerdts <[EMAIL PROTECTED]> wrote: > On Tue, Jul 1, 2008 at 7:31 AM, Darren J Moffat <[EMAIL PROTECTED]> wrote: >> Mike Gerdts wrote: >>> >>> On Tue, Jul 1, 2008 at 5:56 AM, Darren J Moffat <[EMAIL PROTECTED]> >>> wrote: >>>> >>>> Instead we should take it completely out of their hands and do it all >>>> dynamically when it is needed. Now that we can swap on a ZVOL and ZVOLs >>>> can be extended this is much easier to deal with and we don't lose the >>>> benefit of protected swap devices (in fact we have much more than we had >>>> with SVM). >>> >>> Are you suggesting that if I have a system that has 500 MB swap free >>> and someone starts up another JVM with a 16 GB heap that swap should >>> automatically grow by 16+ GB right at that time? I have seen times >>> where applications "require" X GB of RAM, make the reservation, then >>> never dirty more than X/2 GB of pages. In these cases dynamically >>> growing swap to a certain point may be OK. >> >> Not at all, and I don't see how you could get that assumption from what I >> said. I said "dynamically when it is needed". > > I think I came off wrong in my initial message. I've seen times when > vmstat reports only megabytes of free swap while gigabytes of RAM were > available. That is, reservations far outstripped actual usage. Do > you have mechanisms in mind to be able to detect such circumstances > and grow swap to a point that the system can handle more load without > spiraling to a long slow death?
Having this dynamic would be nice with Oracle. 10g at least will use DISM in the preferred configuration Oracle is now preaching to DBAs. I ran into this a few months ago on an upgrade (Solaris 8 -> 10, Oracle 8 -> 10g, and hw upgrade). The side effect of using DISM is that it reserves an amount equal to the SGA in swap, and will fail to startup if swap is too small. In practice, I don't see the space ever being touched (I suspect it's mostly there as a requirement for dynamic reconfiguration w/ DISM, but didn't bother to dig that far). _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
