Shulou(Shulou.com)06/02 Report--

This article focuses on "how to use dotnet-* tools correctly". Interested friends may wish to have a look. The method introduced in this paper is simple, fast and practical. Let's let the editor learn "how to use dotnet-* tools correctly".

Installation

Since we are all in the containerization era, we can make all these tools into basic images.

Prepare Dockerfile

FROM mcr.microsoft.com/dotnet/sdk:3.1 AS sdkRUN dotnet tool install-- tool-path / tools dotnet-traceRUN dotnet tool install-- tool-path / tools dotnet-countersRUN dotnet tool install-- tool-path / tools dotnet-dumpRUN dotnet tool install-- tool-path / tools dotnet-gcdumpFROM mcr.microsoft.com/dotnet/core/aspnet:3.1 AS runtimeWORKDIR / toolsCOPY-- from=sdk / tools .basedockerfile.yaml verify that the basic image is ready. If you check it, the size of the image should be tens of megabytes more than that of runtime. Compared with using sdk directly in order to use dotnet-* tool, it is much smaller and can be verified by a random demo program with the basic image we just made.

The tools folder is already included and our tools tools are stored in it

Take dotnet-trace as an example, test whether it is available (ps: pay attention to how to use it)

At this point, the basic runtime image including tools has been created. Dotnet-dump can only collect managed memory, but cannot be used for problems that are native code, and the analysis of the dump files it creates must be consistent with the current environment. Createdump it can collect both local and managed information. It is a more comprehensive and recommended method. Although gdb and gcore can also play the same role, they may miss some managed status when collecting. This results in a "UNKNOWN" error when you finally analyze the dump file. This tool is installed with. Net core runtime, and the directory is usually used under "/ usr/share/dotnet/shared/Microsoft.NETCore.App/ [version]":

/ usr/share/dotnet/shared/Microsoft.NETCore.App/3.1.10/createdump-u 1 (1 is the process id of the program in my container)

He will generate the coredump file to the container's tmp directory. If there is no error so far, it is successful.

If you report permission related errors, you can add the following to your yaml file:

Analyze the coredump file and first copy the coredump file generated above under tmp to kubectl cp bookstore/demo-7b6d9f6d4f-2t8hl:/tmp/coredump.1 / root/mydump/coredump.1-c app-k8s where you can debug.

Then download the associated symbol for our coredump.1 file: if you are going to analyze the dump machine without dotnet sdk, install a

Sudo rpm-Uvh https://packages.microsoft.com/config/centos/7/packages-microsoft-prod.rpm

Sudo yum install dotnet-sdk-3.1

If dotnet-symbol is not installed, install a

Dotnet tool install-global dotnet-symbol

Then close the current terminal and open a new one

Then execute dotnet-symbol-- host-only-- debugging coredump.1

Seeing that the dac,dbi file is written means it is successful, and your folder should look like this

Then we use lldb to debug

If you don't have one in your machine, install one first.

Install the sos plug-in:

Dotnet tool install-global dotnet-sos

Dotnet-sos install

Lldb-8-core coredump.1

Then you can use lldb to analyze the dump file

At this point, I believe you have a deeper understanding of "how to use dotnet-* tools correctly". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.