From: Nikolay Borisov <kernel@kyup.com>
To: qiaonuohan <qiaonuohan@cn.fujitsu.com>, kexec@lists.infradead.org
Cc: SiteGround Operations <operations@siteground.com>
Subject: Re: Reducing the size of the dump file/speeding up collection
Date: Thu, 17 Sep 2015 09:32:44 +0300 [thread overview]
Message-ID: <55FA5E8C.9020506@kyup.com> (raw)
In-Reply-To: <55FA332B.40408@cn.fujitsu.com>
Hi Qiao,
Thanks for the reply. So far I haven't been using the the compression
feature of makedumpfile. But I want to ask if anything wouldn't
compression make the dump process slower since in addition to having to
write the dump to disk it also has to compress it which would put more
strain on the cpu. Also, which part of the dump process is the bottleneck:
- Reading from /proc/vmcore - that has mmap support so should be fairly
fast?
- Discarding unnecessary pages as memory is being scanned?
- Writing/compressing content to disk?
Regards,
Nikolay
On 09/17/2015 06:27 AM, qiaonuohan wrote:
> On 09/16/2015 04:30 PM, Nikolay Borisov wrote:
>> Hello,
>>
>> I've been using makedumpfile as the crash collector with the -d31
>> parameter. The machine this is being run on usually have 128-256GB of
>> ram and the resulting crash dumps are in the range of 14-20gb which is
>> very bug for the type of analysis I'm usually performing on crashed
>> machine. I was wondering whether there is a way to further reduce the
>> size and the time to take the dump (now it takes around 25 minutes to
>> collect such a dump). I've seen reports where people with TBs of ram
>> take that long, meaning for a machine with 256gb it should be even
>> faster. I've been running this configuration on kernels 3.12.28 and 4.1
>> where mmap for the vmcore file is supported.
>>
>> Please advise
>
> Hi nikolay,
>
> Yes, this issue is what we are concerning a lot.
> About the current situation, try --split, it will save time.
>
>
> And lzo/snappy instead of zlib, these two compression format are faster
> but need more space to save. Or if you still want zlib (to save space),
> try multiple threads, check the following site, it will help you:
>
> https://lists.fedoraproject.org/pipermail/kexec/2015-September/002322.html
>
>
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2015-09-17 6:33 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-16 8:30 Reducing the size of the dump file/speeding up collection Nikolay Borisov
2015-09-17 3:27 ` qiaonuohan
2015-09-17 6:32 ` Nikolay Borisov [this message]
2015-09-17 7:08 ` Nikolay Borisov
2015-09-18 2:38 ` qiaonuohan
2015-09-18 12:45 ` Nikolay Borisov
2015-09-21 6:27 ` qiaonuohan
2015-09-23 1:44 ` Baoquan He
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=55FA5E8C.9020506@kyup.com \
--to=kernel@kyup.com \
--cc=kexec@lists.infradead.org \
--cc=operations@siteground.com \
--cc=qiaonuohan@cn.fujitsu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox