system_setup: add kernel crash dump configuration about azure-li-services HOT 8 CLOSED

we can enable that in the image. But I need to know the setup which fits your needs. We would need to provide the kernel parameter:

crashkernel=SIZE_HIGH,high crashkernel=SIZE_LOW,low

The values for size_high and size_low should come from your side as I could not run
kdumptool calibrate on a real instance of yours. Please advise

Thanks

from azure-li-services.

I'm not 100% sure what you're asking. All I was told from the hardware vendor is that we should enable kernel dumps at dump level 31.

Do I need to go back to the hardware vendor and ask more questions? Or can I run something on the blade that will answer your question?

from azure-li-services.

yeah well dump level 31 doesn't tell me much. You can call the following on the blade

kdumptool calibrate

and send the output here. Especially the values for Low and High are of interest. Thanks

from azure-li-services.

Here's the output from the blade:

linux:~ # kdumptool calibrate
Total: 1572570
Low: 72
High: 154
MinLow: 72
MaxLow: 1747
MinHigh: 0
MaxHigh: 1570816
linux:~ #

Note that this blade isn't under load. The O/S is installed, and that's about it. Not sure if that's important or not.

from azure-li-services.

all right, thanks this turns out to be not so easy. Please could you take a look here

• https://www.suse.com/documentation/sles-12/singlehtml/book_sle_tuning/book_sle_tuning.html#cha.tuning.kexec

and go to the section:

• PROCEDURE 17.1: ALLOCATION SIZE ON AMD64/INTEL 64

There is a recommendation to adjust the values you provided above but I don't seem how I can calculate it without further information.

Thanks

from azure-li-services.

This is yucky.

I read the document and it mixed two concepts:

• Kexec to switch kernels, which I have no need for, and
• Kdump to capture a kernel dump, which I do have a need for

I had no idea that determining kernel dump sizes was so involved. In Procedure 17.1: Allocation Size on AMD64/Intel 64, item 4, it said Finding the right size can therefore be a process of trial and error. They did give some guidance for SAP HANA, but still: we have a number of different SKUs with different memory capacities. Do we need to do this trial and error testing on each of our SKUs?

I guess I'm not quite clear where to go from here. Reading over the page, it didn't give any other commands to try. It did give HANA guidance. What would we do, set up HANA (to cover our bases), set the size as per SAP HANA guidance, then try triggering a core and seeing what happened? Does it matter if SAP HANA is installed for this test? If it does matter, how large/populated does the database need to be (this varies by customer).

Where do I go from here? What, exactly, do we need to do to get the right numbers? And do we need to do this testing on each of our possible SKUs for memory sizing?

from azure-li-services.

HANA does not need to be installed for testing purposes. Here is my proposal to handle this:

Given that we have multiple SKUs with various memory sizes we should include size_high and size_low in the YAML file. A new service azure-li-kdump-config reads this information and modifies /etc/sysconfig/kdump file accordingly (KDUMP_COMMANDLINE_APPEND). The the service then enables and starts kdump

systemctl enable kdump
systemctl start kdump

The values for HIGH and LOW can be static and are predetermined based on running

kdumptool calibrate

on the various blades.

As far as the level is concerned, "31" is the default setting in /etc/sysconfig/kdump

from azure-li-services.

Given that we have multiple SKUs with various memory sizes we should include size_high and size_low in the YAML file

ok that's basically what I wanted to know. So yes this needs to be a dynamic configuration and can be handled the way you suggested it.

All clear now

from azure-li-services.