[RFC] makedumpfile-1.5.1 RC
vgoyal at redhat.com
Tue Nov 20 11:35:45 EST 2012
On Tue, Nov 20, 2012 at 05:14:55AM -0700, Lisa Mitchell wrote:
> I tested this makedumpfile v1.5.1-rc on a 4 TB DL980, on 2.6.32 based
> kernel, and got good results. With crashkernel=256M, and default
> settings (i.e. no cyclic buffer option selected), the dump successfully
> completed in about 2 hours, 40 minutes, and then I specified a cyclic
> buffer size of 48 M, and the dump completed in the same time, no
> measurable differences within the accuracy of our measurements.
This sounds little odd to me.
- With smaller buffer size of 48M, it should have taken much more time
to finish the dump as compared to when no restriction was put on
buffer size. I am assuming that out of 256M reserved, say around 128MB
was available for makedumpfile to use.
- Also 2 hours 40 minutes sounds a lot. Is it practical to wait that
long for a machine to dump before it can be brought into service
again? Do you have any data w.r.t older makedumpfile (which did not
have cyclic buffer logic).
I have some data which I collected in 2008. 128GB system took roughly
4 minutes to filter and save dumpfile. So if we scale it linearly
then it should take around 32minutes per TB. Hence around 2 hours
8 minutes for a 4TB systems. Your numbers do seems to be in roughly
Still 2-2.5 hours seems too long to be able to filter and save core of a
4TB system. We will probably need to figure out what's taking so much of
time. May be we need to look into cliff wickman's idea of kernel returning
list of pfns to dump and make dump 20 time faster. I will love to have 4TB
system dumped in 6 minutes as opposed to 2 hrs. :-)
More information about the kexec