On Mon, Jun 30, 2008 at 9:19 AM, jan damborsky <[EMAIL PROTECTED]> wrote: > Hi Mike, > > > Mike Gerdts wrote: >> >> On Wed, Jun 25, 2008 at 11:09 PM, Jan Damborsky <[EMAIL PROTECTED]> >> wrote: >>> >>> Thank you very much all for this valuable input. >>> >>> Based on the collected information, I would take >>> following approach as far as calculating size of >>> swap and dump devices on ZFS volumes in Caiman >>> installer is concerned. >>> >>> [1] Following formula would be used for calculating >>> swap and dump sizes: >>> >>> size_of_swap = size_of_dump = MAX(512 MiB, MIN(physical_memory/2, 32 >>> GiB)) >> >> dump should scale with memory size, but the size given is completely >> overkill. On very active (heavy kernel activity) servers with 300+ GB >> of RAM, I have never seen a (compressed) dump that needed more than 8 >> GB. Even uncompressed the maximum size I've seen has been in the 18 >> GB range. This has been without zfs in the mix. It is my >> understanding that at one time the arc was dumped as part of kernel >> memory but that was regarded as a bug and has sense been fixed. If >> the arc is dumped, a value of dump much closer to physical memory is >> likely to be appropriate. > > I would agree that given the fact, user can customize this any time > after installation, the smaller upper bound is the better. Would > it be fine then to use 16 GiB, or even smaller one would be more > appropriate ?
By default, only kernel memory is dumped to the dump device. Further, this is compressed. I have heard that 3x compression is common and the samples that I have range from 3.51x - 6.97x. If you refer to InfoDoc 228921 (contract only - can that be opened or can a Sun employee get permission to post same info to an open wiki?) you will see a method for approximating the size of a crash dump. On my snv_91 virtualbox instance (712 MB RAM configured), that method gave me an estimated (uncompressed) crash dump size of about 450 MB. I induced a panic to test the approximation. In reality it was 323 MB and compress(1) takes it down to 106 MB. My understanding is that the algorithm used in the kernel is a bit less aggressive than the algorithm used by compress(1) so maybe figure 120 - 150 MB in this case. My guess is that this did not compress as well as my other samples because on this smaller system a higher percentage of my kernel pages were not full of zeros. Perhaps the right size for the dump device is more like: MAX(256 MiB, MIN(physical_memory/4, 16 GiB) Further, dumpadm(1M) could be enhanced to resize the dump volume on demand. The size that it would choose would likely be based upon what is being dumped (kernel, kernel+user, etc.), memory size, current estimate using InfoDoc 228921 logic, etc. >> As an aside, does the dedicated dump on all machines make it so that >> savecore no longer runs by default? It just creates a lot of extra >> I/O during boot (thereby slowing down boot after a crash) and uses a >> lot of extra disk space for those that will never look at a crash >> dump. Those that actually use it (not the majority target audience >> for OpenSolaris, I would guess) will be able to figure out how to >> enable (the yet non-existent) svc:/system/savecore:default. >> > > Looking at the savecore(1M) man pages, it seems that it is managed > by svc:/system/dumpadm:default. Looking at the installed system, > this service is online. If I understand correctly, you are recommending > to disable it by default ? "dumpadm -n" is really the right way to do this. -- Mike Gerdts http://mgerdts.blogspot.com/ _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
