Re: [Xen-devel] how to generate a smaller core with xm dump-core

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2015-01-15 at 11:31 +0800, Zhenzhong Duan wrote:
> Hi Maintainers,
> 
> 
> We are facing issue collecting  coredump using the xm dump mechanism
> in Dom0.
> 
> We face couple of such issues daily, where the VMs panic s and the SA
> team is supposed to collect the core.
> 
> The actual problem is that where the VMs are having huge RAM like 32+
> GB RAMs dumping the core using xm dump generated core of almost the
> same size. 
> 
> And also when the RAM size is huge the time taken to dump is also
> huge.
> 
> Transferring this core dump of this huge size to another system for
> analysis is really a pain. I am looking for some solution where we can
> generate smaller core using xm dump or any other tool.
> 
> Something similar to makedumpfile which eliminates the zero and
> unnecessary pages, which results in core of smaller size.
> 
>  
> 
> This has become a hot issue and we terribly need this feature.
> 
> Can you come across with anything or are you aware of any feature
> which could cater our needâ.?

I'm not aware of any existing features or efforts in this area.

If things like zero pages can be omitted from a core file without making
it non-standard then I think we'd be happy to see such patches to the
core libxc functions which produce the core files.

That wouldn't help much with a heavily loaded VM which is making good
use of all its ram though.

I've not looked but it's not unlikely that the dumping code itself is
not very optimal, so it might be worth having a look to see if more
batching etc might help speed things up at the root. Ages ago there were
patches floating around which improved the performance of the privcmd
mmap ioctl (from Mats Peterson), which might help here too (assuming
core dumping uses those interfaces as I expect). AFAIK those patches
were abandoned when Mats moved onto other things, resurrecting them
would probably help here as well as with migration and other
foreign-memory-man heavy workloads.

Other random thoughts:
      * Automatically compress the core file, doesn't help with time to
        produce the dump (quite the opposite) but helps with copying it
        off box (but could also compress manually before moving or do it
        as a post processing step)
      * Have an option to produce some kind of "minicore", e.g. just
        register state and a few pages of the referenced stacks, perhaps
        a few pages of RAM either side of any register which happens to
        be a valid looking pointer.
              * Care would be needed to retain an acceptable probability
                that the resulting core will actually be useful.
      * Consider including kernel RAM only (which might still be huge
        though if it has a 1:1 mapping of all RAM).

I don't think any of those would be suitable for enabling by default but
they might be useful to have in the arsenal.

HTH,

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel