Size of system dump device!

[Chris Fung]

Hi all,

Any idea on the size of system dump device?

Since we never know how many memory space has been used when the system crash unexpectedly, so the safest way to preserve the system dump is to set the size of the system dump device same as the memory size !!
Please comments,

Many thanks,

Chris,

[Stefan Farrelly]

Normally you set the lvol dump device to be the same lvol as for swap - and your swap size should be the same size as physical memory (for performance reasons) so yes, RAM = swap size = dump size so that way if you have a crash you will always get a complete dump!

eg.

Boot: lvol1 on: /dev/dsk/c0t6d0
Root: lvol3 on: /dev/dsk/c0t6d0
Swap: lvol2 on: /dev/dsk/c0t6d0
Dump: lvol2 on: /dev/dsk/c0t6d0

[Michael Tully · Accepted solution]

Hi Chris,

The size you've mentioned is not necessarily correct. If and when there is a crash dump, the dump is actually compressed. The dump itself is usually less than half of the memory and the default location is /var anyway.
In my opinion, if /var is at least 2Gb you
will most likely get all of it anyway. For systems that have *really* large memory you can increase this actual dump space to about 30-40% of memory. This should be enough.

Michael

[Chris Fung]

Dear guys,

Thanks for your advices. I have one more question:

During what situation, the system will generate system dump to the dump device(s) and in what situation will generate a core dump file directly into the filesystem ?

Is that the first one kernel level related ? While the second one is user level related ? I need to identify the difference so that I can decide how to organize my dump devices as well as size the filesystem effectively to hold the core dump file(s).

Many thanks,

Chris,

[U.SivaKumar_2]

Hi,
The file system core dump is generated by a separate PROCESS which have met a undesired
situation while running.

But the Dump in the dump devices is due to the
KERNEL which have met some undesired circumstances such as memory overflow, Hardware
problems ( HPMC ), kernel spins etc. Hence it
dumps everthing in the system's memory at the
time of crash to the dump devices for failure
analysis .


regards,
U.SivaKumar

[Michael Tully]

Hi Chris,

A system dump is generated after a system panic situation, where the information that was stored in memory is released to disk during the subsequent system boot providing there is sufficient space to do so. Your last 'dmesg' output will normally tell you. There are a few files generated, and stored
including a copy of the kernel. By default into /var/adm/crash. If your /var filesystem is big enough this is a good place. You can create an additional filesystem for storage depending on your save crash conf. Have a look at how you have the /etc/rc.config.d/savecrash file configured. (depending on your OS level, I have no access to a system right now) As long as your dump file space has enough space, the memory dump will be placed. As I've mentioned /var should be large enough, but should you wish to create another space, and keep it reserved, adding an additional filesystem will do the trick and have it configured accordingly in your /etc/rc.config.d/savecrash file will save it as lomg as it is mounted as run level two.

[Chris Fung]

Dear guys,

Thanks for your valuable information. Now I have a better understanding on the system dump.

Right now I am thinking about how to handling the core dump file generated irregularly. Since all users defined in the Unix machine are able to execute programs, they are able to create huge core dump files.... I am thinking to limit the size of the core dump file generate for Unix users. Since those core dump file will be removed as soon as they generated and I don't see anyone inside our organization will spent time to read through the core dump. Is it a good approach to deal with it? Any comments? Appreciate it if you can provide any resource link for this topic.

Cheers,

Chris,

[MANOJ SRIVASTAVA]

Hi Chris

Also you amy like to look at this :

http://docs.hp.com/cgi-bin/fsearch/framedisplay?top=/hpux/onlinedocs/B2355-90672/B2355-90672_top.html&con=/hpux/onlinedocs/B2355-90672/00/00/66-con.html&toc=/hpux/onlinedocs/B2355-90672/00/00/66-toc.html&searchterms=DUMP%7cPARTITIONS&queryid=20020709-084056

The amount of disk space made available for core dumps should accommodate your system's physical (core) memory. (If you need to determine the amount of physical memory on your system, see "Estimating Your Swap Space Needs" earlier in this chapter.)

Because the physical memory on your system may exceed the space available in the primary swap area, you may wish to configure additional disk space for the full core memory image. Otherwise, only a partial core image will be saved which may not be sufficient for analyzing problems.



Manoj Srivastava

[James R. Ferguson]

Hi Chris:

With regard to your last question of limiting the size of a user's program core file, you can place, in each user's profile, the following:

# ulimit -c 0

This sets the resource limit for core files to zero 512-byte blocks. See the man pages for 'sh-posix'.

Regards!

...JRF...

[Sridhar Bhaskarla]

Chris,

You already received excellent responses for the system core dump.

in POSIX shell you have the option of specifiying core limit with ulimit -c command.
Other shells do not recognise this option.

ulimit -c 2048 will limit the core files to 1 MB.

Only core files that are in this limit are dumped by the processes.

-Sri

[A. Clay Stephenson]

Hi Chris:

I fundamentally disagree with your approach to handling program core dumps. This is not a Windows box; program crashes (other than user-induced) are not considered routine events. I can tell you that the number of core files I see on my production boxes is vanishingly small and that is as it should be. Most software vendors will work with you to correct their mistakes; some may require a little gentle persuasion.

Food for thought, Clay