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. In most cases, however, I see this as a recipe for disaster. I would rather have an application die (and likely restart via SMF) because it can't get the memory that it requested than have heavy paging bring the system to such a crawl that transactions time out and it takes tens of minutes for administrators to log in and shut down some workload. The app that can't start will likely do so during a maintenance window. The app that causes the system to crawl will, with all likelihood, do so during peak production or when the admin is in bed. Perhaps bad paging activity (definition needed) should throw some messages to FMA so that the nice GUI tool that answers the question "why does my machine suck?" can say that it has been excessively short on memory X times in recent history. Any of these approaches is miles above the Linux approach of finding a memory hog to kill. -- Mike Gerdts http://mgerdts.blogspot.com/ _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
