Systemd coredump что это

Как полностью отключить создание дампов памяти : Linux

Coredump — это дамп закрытой памяти процесса, создаваемый в момент возникновения в нём внештатной ситуации, приводящей к аварийному завершению. Эти дампы используются всевозможными системами анализа и необходимы для создания правильных баг-репортов.

По умолчанию systemd при падениях любых процессов (как системных, так и пользовательских), сохраняет дампы их закрытой памяти в каталоге /var/lib/systemd/coredump, поэтому он может занимать десятки гигабайт.

Чтобы отключить создание этих дампов, надо поправить файл

Уберём символ комментария # лишь перед первой строкой и изменим её значение:

[Coredump] Storage=none

Часовой пояс GMT +3, время: 18:13 .

Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.

Sysadminium

В этой статье я расскажу, как можно настроить сохранение дампов в Linux при падении процессов, такие дампы называют core dumps.

Оглавление скрыть

Введение

При работе в Linux у вас запускается множество процессов, но иногда какой-нибудь процесс может начать падать. Или какая-нибудь программа может не запускаться. Иногда разработчики для анализа таких ситуаций просят выслать им дамп ядра (core dumps) относящийся к падению их программы.

Вообще core dumps никак не связан с ядром Linux. Термин «Ядро» в этом случае относится к старой памяти на магнитных сердечниках из старых систем (magnetic core memory). Хотя такая память уже не используется, но термин core dumps всё еще употребляется.

В core dumps сохраняется память сбойного процесса при его падении, а также некоторая служебная информация.

Ограничение на размер дампа

Самое главное ограничение, которое говорит системе, делать дамп упавшего процесса или не делать — это ограничение максимального размера дампа. Если это ограничение равняется 0 — то дамп не будет делаться совсем. Также вы можете ограничить максимальный размер дампа произвольным числом в байтах, или отключить лимит вовсе.

Посмотреть текущее ограничение для своего пользователя и своей оболочки можно выполнив команду:

$ ulimit -S -c 0

В выводе у меня 0 — это означает что создание дампов под моим пользователем и в моём окружении невозможно.

Командой выше мы смотрели мягкое (soft) ограничение. Это фактическое ограничение, которое влияет на процессы.

Есть ещё жесткое ограничение (hard), его может поменять только root пользователь. Давайте посмотрим как сейчас нас ограничивает жёсткое ограничение:

$ ulimit -H -c unlimited

Из этого следует, что сейчас жёсткое ограничение нас вообще не ограничивает. Поэтому мы можем изменить для себя мягкое ограничение и разрешить создание дампов. Это делается командой:

$ ulimit -c unlimited

$ ulimit -S -c unlimited

Куда сохранять дампы ядра

Чтобы узнать, куда сейчас сохраняются дампы ядра, нужно прочитать файл /proc/sys/kernel/core_pattern:

*** Debian 11 *** $ cat /proc/sys/kernel/core_pattern core *** Ubuntu 22.04 *** $ cat /proc/sys/kernel/core_pattern |/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E

Debian называет файлы дампов именем core и куда-то их сохраняет (если честно, я не выяснял куда).

Ubuntu через пайп передаёт дамп на обработку программе apport.

Вы можете временно (до перезагрузки) изменить путь и имя дампов задав свой шаблон, например таким способом:

$ sudo sysctl -w kernel.core_pattern=/var/crash/core.%u.%e.%p

Выше мы меняем параметр sysctl — kernel.core_pattern. И задаём ему значение состоящее из пути и имени файла, а также используем переменные:

• %u — имя пользователя (под каким пользователем работала упавшая программа);
• %e — имя программы;
• %p — номер процесса (pid).

Проверим что путь изменился. Затем нужно создать этот каталог, если его ещё не существует и убедиться что наш пользователь сможет в него писать.

*** Ubuntu 22.04 *** $ cat /proc/sys/kernel/core_pattern /var/crash/core.%u.%e.%p $ ls -ld /var/crash/ drwxrwxrwx 2 root root 4096 апр 21 01:01 /var/crash/ *** Debian *** $ cat /proc/sys/kernel/core_pattern /var/crash/core.%u.%e.%p $ ls -ld /var/crash/ ls: невозможно получить доступ к '/var/crash/': Нет такого файла или каталога $ sudo mkdir /var/crash/; sudo chmod 777 /var/crash/ $ ls -ld /var/crash/ drwxrwxrwx 2 root root 4096 мая 31 15:50 /var/crash/

Хорошо, путь мы поменяли и каталог по этому пути сделали доступным. Ограничение на размер дампов для своей оболочки тоже сняли.

Создаём сбойную программу

Для того чтобы проверить что дампы для нас уже выполняются нужно запустить программу, которая точно упадёт. Напишем эту программу сами:

$ nano crash.c int main() < return 1/0; >

Наша программа выполняет деление на 0 и это приводит к сбою.

Теперь нужно откомпилировать эту программу (возможно вам придется установить gcc):

$ gcc -o crash crash.c crash.c: In function ‘main’: crash.c:3:13: warning: division by zero [-Wdiv-by-zero] 3 | return 1/0; | ^

Даже компилятор показывает, что наша программа содержит ошибку деления на ноль.

Теперь запустим программу:

$ ./crash Floating point exception (core dumped)

Программа падает с ошибкой и видно что был сформирован core dumped. Если бы дампы ядра были отключены, этой надписи в скобках не появилось бы.

Посмотрим на наш файл дампа:

$ ls -l /var/crash/ total 120 -rw------- 1 alex alex 299008 мая 31 12:58 core.1000.crash.1397

Настройка создания дампов на постоянной основе

Проделанное выше вернётся к значениям по умолчанию после перезагрузки. Также остальные процессы, которые были запущены от имени других пользователей и в других оболочках не будут создавать дампы при падениях. Исправим это внеся изменения в конфигурационные файлы.

Ограничение на размер дампа

Настройка лимитов производится в конфиге /etc/security/limits.conf или лучше создать отдельный конфиг в каталоге /etc/security/limits.d/.

$ sudo nano /etc/security/limits.d/core.conf root hard core unlimited root soft core unlimited * hard core unlimited * soft core unlimited

Звездочка означает что это правило применимо ко всем пользователям в системе, кроме root. Для root пользователя нужно создавать отдельные правила.

Дальше идет тип ограничения. Soft — это мягкое ограничение, которое фактически ограничивает процессы. А hard — это верхняя граница для soft. Соответственно soft должно быть всегда меньше hard.

Core — это специальное ограничение для дампов ядра. Ограничивать лимитами можно многие параметры, но это выходит за рамки этой статьи.

Unlimited — означает, что мы не ограничиваем размер дампов. Здесь вы можете указать число в байтах, или 0 чтобы совсем выключить создание дампов.

Чтобы внесённые изменения применились к какому-нибудь процессу, этот процесс нужно перезагрузить.

Путь сохранения дампов

Отредактируйте конфиг /etc/sysctl.conf:

$ sudo nano /etc/sysctl.conf kernel.core_pattern=/var/crash/core.%u.%e.%p fs.suid_dumpable=2

Вторым параметром мы разрешаем программам имеющим бит Setuid тоже сохранять дампы при падениях.

Setuid – это бит разрешения, который позволяет пользователю запускать исполняемый файл с правами владельца этого файла. Другими словами, использование этого бита позволяет нам поднять привилегии пользователя в случае, если это необходимо.

Параметр fs.suid_dumpable для sysctl может принимать следующие значения:

• 0 – отключено;
• 1 – включено;
• 2 – включено с ограничениями. Делает дампы ядра доступными для чтения только пользователю root.

Чтобы применить изменения, выполните sysctl с ключом -p.

$ sudo sysctl -p kernel.core_pattern = /var/crash/core.%u.%e.%p fs.suid_dumpable = 2

Разрешаем сохранять дампы службам systemd

Хорошо, путь к созданию дампов мы указали и лимиты для всех пользователей убрали.

Но для сохранения дампов служб работающих в systemd, нам нужно настроить ещё один конфиг.

$ sudo nano /etc/systemd/system.conf DefaultLimitCORE=infinity

Чтобы применить изменения выполните следующие команды:

$ sudo systemctl daemon-reexec $ sudo systemctl restart nginx.service

И чтобы проверить применились ли наши изменения посмотрите информацию о лимитах для процесса nginx:

$ systemctl status nginx.service | grep 'Main PID' Main PID: 2099 (nginx) $ cat /proc/2099/limits | grep 'core' Max core file size unlimited unlimited bytes

В командах выше я вначале получаю PID основного процесса nginx, а затем использую его, чтобы посмотреть лимиты этого процесса.

Вот теперь nginx сможет сохранить дамп при падении.

Сохранения дампа при падении nginx

Чтобы имитировать падение nginx, убьём его главный процесс отправив сигнал SIGSEGV:

$ sudo kill -s SIGSEGV 2099

Проверим что дамп появился:

$ ls -l /var/crash/ total 1940 -rw------- 1 root root 2347008 мая 31 13:41 core.0.nginx.2099 -rw------- 1 alex alex 299008 мая 31 12:58 core.1000.crash.1397

Чтение дампов ядра

Чтобы понять что произошло нужно прочитать дамп ядра. Для этого используется утилита gdb (её нужно установить). Вначале указывается путь к программе, затем путь к дампу:

*** Дамп нашей сбойной программы *** $ gdb ./crash /var/crash/core.1000.crash.1397 Program terminated with signal SIGFPE, Arithmetic exception. Программа завершилась с сигналом SIGFPE, арифметическое исключение. *** Дамп процесса nginx *** $ sudo gdb /usr/sbin/nginx /var/crash/core.0.nginx.2099 Program terminated with signal SIGSEGV, Segmentation fault. Программа завершена с сигналом SIGSEGV, ошибка сегментации.

Вывод

Дампы ядра могут быть полезны для устранения неполадок, но могут стать причиной утечки конфиденциальных данных. По возможности отключайте дампы ядра и включайте их только тогда, когда это действительно необходимо. И проверяйте, надежно ли хранятся файлы, чтобы обычные пользователи не могли видеть их. И независимо от того, какой выбор вы сделали, всегда проверяйте, работает ли ваша конфигурация именно так, как вы ожидаете.

Имя статьи
Настройка дампов ядра (core dumps) в Linux

В этой статье я расскажу, как можно настроить сохранение дампов в Linux при падении процессов, такие дампы называют core dumps

Core dump (Русский)

Состояние перевода: На этой странице представлен перевод статьи Core dump. Дата последней синхронизации: 15 февраля 2022. Вы можете помочь синхронизировать перевод, если в английской версии произошли изменения.

Дамп памяти (core dump) — это файл, в который записывается адресное пространство (память) процесса при его нештатном завершении. Дампы ядра могут создаваться по требованию (например, отладчиком) или автоматически при завершении процесса. Дампы памяти создаются ядром при сбое программы и могут быть переданы вспомогательной программе (например, systemd-coredump(8) ) для дальнейшей обработки. Дамп памяти обычно не используется обычным пользователем, но может быть передан разработчикам по их запросу, которым будет очень полезно иметь снимок состояния программы на момент сбоя, особенно если сбой трудно воспроизвести.

Отключение автоматических дампов памяти

Пользователи могут захотеть отключить автоматические дампы памяти по нескольким причинам:

• Производительность: создание дампа для процессов, занимающих много памяти, может привести к трате системных ресурсов и задержке очистки памяти.
• Дисковое пространство: дампы процессов, занимающих много памяти, могут занимать место на диске, равное, а то и большее, чем объём памяти процесса, если их не сжимать.
• Безопасность: хотя дампы обычно может читать только root, они могут содержать конфиденциальные данные (например, пароли или криптографические ключи), которые записываются на диск после сбоя.

Используя sysctl

Можно использовать sysctl, чтобы изменить kernel.core_pattern для отключения дампов. Создайте файл:

/etc/sysctl.d/50-coredump.conf

kernel.core_pattern=/dev/null

Для немедленного применения изменений используйте команду sysctl :

# sysctl -p /etc/sysctl.d/50-coredump.conf

Используя systemd

Поведение systemd по умолчанию определено в файле /usr/lib/sysctl.d/50-coredump.conf , который прописывает kernel.core_pattern для вызова systemd-coredump . Он сохраняет дампы ядра для всех процессов в /var/lib/systemd/coredump . Поведение systemd-coredump можно переопределить, создав в /etc/systemd/coredump.conf.d/ файл ( coredump.conf(5) § DESCRIPTION ,, [1]):

/etc/systemd/coredump.conf.d/custom.conf

[Coredump] Storage=none

Примечание: Не забудьте прописать имя секции [Coredump] , иначе опция будет проигнорирована.

Затем перезагрузите настройки systemd.

Одного этого метода обычно достаточно для отключения записи дампов, если в системе нет других программ, включающих автоматические дампы, но дамп памяти всё равно генерируется в памяти и systemd-coredump всё равно запускается.

Используя PAM limits

Максимальный размер дампа памяти для пользователей, вошедших в систему через PAM, задаётся в файле limits.conf. Установка нулевого значения полностью отключает дампы памяти. [2]

/etc/security/limits.conf

* hard core 0

Используя ulimit

Командные оболочки вроде bash и zsh имеют встроенную команду ulimit, которую можно использовать для просмотра или изменения ограничений на ресурсы оболочки и запускаемых ею процессов. Подробнее смотрите bash(1) § SHELL BUILTIN COMMANDS или zshbuiltins(1) .

Отключение дампов памяти в текущей командной оболочке:

$ ulimit -c 0

Создание дампа памяти

Чтобы сгенерировать дамп памяти произвольного процесса, сначала установите пакет gdb . Затем найдите PID запущенного процесса, например, с помощью pgrep:

$ pgrep -f firefox

2071 firefox

Подключитесь отладчиком к этому процессу:

$ gdb -p 2071

И затем в отладчике выполните:

(gdb) generate-core-file Saved corefile core.2071 (gdb) quit

Теперь у вас есть дамп памяти в файле core.2071 .

Куда они попадают?

sysctl kernel.core_pattern определяет, куда отправляются автоматические дампы памяти. По умолчанию их принимает systemd-coredump, который настраивается через файл /etc/systemd/coredump.conf . По умолчанию он записывает дампы в /var/lib/systemd/coredump (опция Storage=external ), сжимая их с помощью zstd (опция Compress=yes ). Кроме того, можно настроить различные ограничения на размер хранилища.

Примечание: Значение по умолчанию для kernel.core_pattern задаётся в файле /usr/lib/sysctl.d/50-coredump.conf . Этот файл может быть замаскирован или переопределён для использования другого значения в соответствии с обычными правилами sysctl.d(5) .

Чтобы получить дамп памяти из журнала, смотрите coredumpctl(1) .

Изучение дампа памяти

Команда coredumpctl покажет список сохранённых дампов, среди которых можно найти нужный:

# coredumpctl list

Для поиска нужного дампа можно использовать PID, имя исполняемого файла, путь к исполняемому файлу или предикат journalctl (подробнее: coredumpctl(1) и journalctl(1) ). Просмотр подробностей о дампах ядра:

# coredumpctl info соответствие 

Обратите внимание на строку «Signal», она поможет определить причину сбоя. Для более глубокого анализа вы можете изучить backtrace с помощью gdb:

# coredumpctl gdb соответствие 

После запуска gdb можно использовать команду bt для получения backtrace:

(gdb) bt

Если отладочные символы нужны, но не найдены, можно попробовать получить их, как описано в статье Отладка/Трассировка.

Удаление дампов памяти

Файлы дампов памяти, хранящиеся в /var/lib/systemd/coredump/ , будут автоматически очищаться командой systemd-tmpfiles —clean , которая запускается ежедневно с помощью systemd-tmpfiles-clean.timer . Дампы памяти настроены на хранение не менее 3 дней, смотрите systemd-tmpfiles —cat-config .

Смотрите также

• american fuzzy lop — Инструмент для автоматизированного тестирования ядра и программ
• Filesystem fuzzing — Статья LWN о тестировании файловых систем на наличие ошибок

Retrieved from «https://wiki.archlinux.org/index.php?title=Core_dump_(Русский)&oldid=775028»

• Development (Русский)
• Security (Русский)

Часть 3.3. Отладчики, дампы ядер и сбор дампов ядер

В этой статье представлены отладчики и основные дампы, а также средства для сбора и анализа основных файлов дампа в Linux.

Предварительные требования

Как и в предыдущих частях, эта часть структурирована таким образом, чтобы уделять больше внимания теории и принципам, которые следует следовать при начале устранения неполадок. В нем нет необходимых компонентов. Тем не менее, если вы выполнили все шаги этого обучения до сих пор, у вас должны быть настроены следующие элементы:

• Nginx имеет два веб-сайта:
  • Первый веб-сайт прослушивает запросы с помощью заголовка узла myfirstwebsite ( http://myfirstwebsite ) и направляет запросы в демонстрационное приложение ASP.NET Core, прослушивающее порт 5000.
  • Второй веб-сайт прослушивает запросы с помощью заголовка узла висяб ( http://buggyamb ) и направляет запросы во второй пример приложения ASP.NET Core, прослушивающий порт 5001.

  Цель этой части

  В этой части описывается концепция основных дампов и отладчиков, а также средства, которые можно использовать для записи и анализа основных файлов дампа. Большинство методов и средств, описанных в этой части, будут использоваться в следующих лабораториях по устранению неполадок.

  Основной дамп

  Как и дамп памяти в пользовательском режиме в Windows, основной дамп — это моментальный снимок памяти процесса. Дампы ядер часто необходимы для устранения проблем с производительностью в Linux.

  Отладчик (ручная коллекция дампов) может создать основной дамп по запросу или настроить автоматический сбор данных после сбоя процесса.

  Что происходит при сбое процесса в Linux?

  Большинство систем Linux имеют основные дампы, включенные по умолчанию. Система создает основной дамп для любого процесса, который неожиданно завершается. Это аналогично тому, как отчеты об ошибках Windows (WER) создает дампы для процессов, которые завершаются аномально.

  Ниже приведены некоторые ключевые аспекты поведения системы Linux, связанные с созданием файла дампа ядра.

  • По умолчанию файл дампа ядра создается при неожиданном завершении процесса.
  • Файл дампа Core называется «core» и создается в текущем рабочем каталоге или в каталоге /var/lib/systemd/coredump .
  • Хотя по умолчанию операционная система создает файл дампа ядра, /proc/sys/kernel/core_pattern этот параметр можно перезаписать, чтобы напрямую передать выходные данные файла дампа ядра в другое приложение.

  Эти параметры по умолчанию и некоторые другие параметры, например ограничения размера, можно задать в файлах конфигурации. Следующие ресурсы более подробно описаны в этой теме:

  • Основные дампы
  • Внешняя ссылка: ядро страницы Ubuntu man — файл дампа ядра

  Apport: способ управления дампами ядер в Ubuntu

  В Ubuntu системная служба apport управляет созданием дампа ядра. Даже если создание дампа ядра операционной системы отключено, apport по-прежнему будет создавать файлы дампа ядер.

  Apport использует для /proc/sys/kernel/core_pattern прямой передачи основного файла дампа в apport. При выполнении команды cat /proc/sys/kernel/core_pattern во время работы apport должен отобразится следующий результат.

  

  Если отключить apport, это не помешает созданию дампа ядра после завершения процесса. Вместо этого он просто останавливает apport. Затем система возвратит свое поведение по умолчанию, создав дампы ядер. Если запустить то же самое cat /proc/sys/kernel/core_pattern после остановки apport, вы увидите следующее поведение системы по умолчанию.

  

  Отключение автоматического создания дампа ядра

  Чтобы отключить автоматическое создание файла дампа ядра, выполните следующие действия.

  1. Остановите и отключите apport.
  2. Отключите действие системы по умолчанию.

  Apport можно остановить и отключить так же, как и любую другую службу. Используйте команду sudo systemctl stop apport и команду sudo systemctl disable apport , чтобы остановить службу, а затем отключите ее, чтобы предотвратить ее перезапуск.

  

  Чтобы отключить автоматическое создание файлов дампа операционной системы для всех процессов, которые выполняются во всех учетных записях пользователей на компьютере, необходимо выполнить действия, описанные в таких статьях , как эта.

  Запись основного дампа и отладчика

  Существует несколько средств для записи основного файла дампа, например gcore, gdb и нескольких средств для анализа основного файла дампа, например objdump, kdump, gdb и lldb.

  Однако при работе с этими средствами вы столкнетесь с некоторыми значительными сложностями, чтобы попытаться выполнить отладку .NET:

  • Конфигурация может быть сложной по сравнению с процессом настройки символов для отладчика WinDbg в Windows.
  • Основные файлы дампа большие, так как эти средства не знают, какая область памяти используется в процессе .NET Core, и они не могут обрезать сведения о памяти только до того, что необходимо.
  • Файлы дампа не переносимы. Вам потребуется проанализировать файлы дампа на компьютере Linux, на котором они были созданы. Если вы хотите проанализировать файлы дампа на другом компьютере Linux, необходимо выполнить дополнительные действия, чтобы настроить хост-компьютер для сеанса отладки.

  lldb

  Lldb — это рекомендуемый инструмент для анализа дампа .NET Core. Пакет SDK для .NET содержит полезные средства для правильной настройки lldb. Однако для выполнения такого анализа отладки для .NET Core необходимо установить по крайней мере версию 3.9.

  Чтобы установить lldb 3.9 или более позднюю версию, используйте диспетчер пакетов (например: sudo apt install lldb ).

  Средства и команды, доступные в среде выполнения .NET Core и пакете SDK

  Вместе со средой выполнения .NET Core входит несколько полезных средств. Например, устанавливается createdump как часть каждой установки среды выполнения .NET Core.

  Вы также можете разрабатывать собственные средства или использовать несколько сторонних средств. Платформа Microsoft .NET Core также включает некоторые средства .NET Core, которые полезны для отладки проблем .NET Core. К ним относятся:

  • dotnet-dump
  • dotnet-gcdump
  • dotnet-symbol

  Чтобы установить эти средства вместе с другими, необходимо установить пакет SDK для .NET Core. Дополнительные сведения о пакете SDK для .NET Core см. в статье «Общие сведения о пакете SDK для .NET».

  Procdump также стоит упомянуть, хотя он не является частью пакета SDK. Подробное описание параметров ProcDump можно найти в конце этой части.

  createdump

  Createdump устанавливается в каждой версии .NET Core. Дополнительные сведения см. в сведениях о реализации.

  Createdump — лучший способ создать файл дампа ядра в Linux. Это связано с тем, что файлы дампа, автоматически создаваемые системой, могут включать не все управляемые состояния. Кроме того, некоторые команды SOS или dotnet-dump могут отображать «UNKNOWN» для имен типов и функций.

  Аналогичным образом файлы дампа вручную, созданные с помощью gdb или gcore, не будут содержать все сведения об управляемом состоянии, а некоторые команды SOS или dotnet-dump также могут отображать «UNKNOWN» для имен типов и функций. Для записи файлов дампа вручную рекомендуется использовать createdump или другое средство .NET Core, например procdump.

  Ниже приведены некоторые важные функции createdump:

  • Минидампы минимального размера создаются автоматически.
  • Вы можете легко настроить пользователя, не являгося корневым.
  • Его можно использовать для записи файлов дампа ядра сбоя системы или по запросу (вручную).
  • Обнаруживается большинство сбоев переполнения стека.

  Для анализа основных файлов дампа, собранных с помощью createdump, необходимо использовать lldb 3.9 или более позднюю версию.

  Файл createdump можно найти в каталоге установки .NET Core. Чтобы найти этот каталог, выполните команду dotnet —list-runtimes . Как показано на следующем снимке экрана, для двух версий активных сред выполнения был создан отдельный файл createdump.

  

  dotnet-dump

  Чтобы установить это средство, необходимо установить пакет SDK для .NET Core. Dotnet-dump появился в пакете SDK для .NET Core 3.0. Он помогает собирать и анализировать основные файлы дампа без необходимости в собственном отладчике. Он позволяет выполнять команды SOS для анализа сбоев и вывода сборщика мусора (GC).

  Dotnet-dump не является собственным отладчиком. Поэтому некоторые функции, такие как отображение собственных кадров стека, недоступны. Созданный файл дампа не является переносимым, и его нельзя открыть в Windows.

  Чтобы установить это средство, выполните следующую команду:

  dotnet tool install -g dotnet-dump 

  Это средство будет использоваться для записи и анализа основных файлов дампа в следующих разделах лаборатории.

  dotnet-gcdump

  Это еще одно средство, для которого требуется пакет SDK для .NET Core. Dotnet-gcdump доступен в .NET Core 3.1 или более поздних версиях.

  Это интересный подход для анализа кучи мусора. Идея этого средства заключается в том, что полный файл дампа процесса не требуется для исследования во многих сценариях. Таким образом, средство записывает только сведения об управляемой куче и создает на их основе отчет.

  Самое важное, что файлы дампа, созданные этим средством, переносимы и могут быть проанализированы в PerfView или Visual Studio в Windows.

  Как кратко описано здесь, с помощью этого средства запускается полная сборка мусора для потоковой передачи информации в «канал событий» для создания файла дампа.

  Так как в целевом процессе запускается полная сборка мусора 2-го поколения, характеристики производительности приложения можно изменить. Как и ожидалось, пока сведения записываются в файл дампа ядра, потоки будут приостановлены. Чем больше размер кучи, тем дольше приостановка записи информации в файл, и чем дольше потоки будут приостановлены.

  Сведения, содержащиеся в таких основных файлах дампа, будут полезны в следующих случаях:

  • Сравнение количества объектов по типу в управляемой куче
  • Анализ корней объектов
  • Определение объектов, которые имеют ссылку на тип
  • Другой статистический анализ объектов в куче

  После создания данных файл можно экспортировать за пределы компьютера, на котором он был создан, и его можно проанализировать в PerfView или Visual Studio.

  Чтобы установить это средство, выполните следующую команду:

  dotnet tool install -g dotnet-gcdump 

  Эта команда будет использоваться для создания некоторых отчетов для куч .NET Core в следующих разделах лаборатории.

  dotnet-symbol

  Dotnet-symbol — это полезное средство для получения символов для управляемой отладки. Он появился в .NET Core 2.1. Как и для двух других средств, упомянутых выше, для этих средств также требуется установить пакет SDK для .NET Core.

  Dotnet-symbol загружает все файлы, необходимые для отладки (символы, модули, SOS и DAC для модуля coreclr) для любого основного файла дампа.

  Чтобы установить это средство, выполните следующую команду:

  dotnet tool install -g dotnet-symbol 

  Это средство будет использоваться для настройки отладчика в следующих разделах лаборатории.

  procdump

  Также доступна версия ProcDump для Linux . Он имеет некоторые ограниченные наборы функций по сравнению с его аналогом Windows. Он поддерживает не все функции, которые использует версия Windows. Например, его нельзя настроить для сбора файлов дампа ядер при сбое процесса или возникновении первого исключения. Однако это по-прежнему мощный инструмент.

  Следующие параметры командной строки для создания файлов дампа ядра триггера ProcDump в указанных условиях.

  -C: CPU exceeds or equals a specified value (0 to 100 * nCPU) -c: CPU is less than a specified value (0 to 100 * nCPU) -M: The memory commit exceeds or equals a specified value (MB) -m: The memory commit is less than a specified value (MB) -T: The thread count exceeds or equals a specified value -F: The filedescriptor count exceeds or equals a specified value 

  Следуйте инструкциям по установке ProcDump в своей среде.

  Это средство будет использоваться для записи основного файла дампа, основанного на использовании ЦП в следующих разделах лаборатории.

  Примечание о выборе версии пакета SDK

  По умолчанию пакет SDK устанавливается в «параллельной» конфигурации. Это означает, что несколько версий могут работать вместе на одном компьютере. Выбор версии при выполнении команд интерфейса командной строки более подробно описан в статье «Выбор версии .NET Core для использования «. Однако процесс выбора версии пакета SDK можно суммировать следующим образом:

  • .NET Core выполняет поиск файла global.json итеративно в обратном направлении, переходя по пути вверх из текущего рабочего каталога.
  • .NET Core использует пакет SDK, указанный в первом найденном файле global.json .
  • .NET Core использует последний установленный пакет SDK, если экземпляр global.json не найден.

  Например, на тестовой виртуальной машине Linux должны быть установлены пакеты SDK для .NET Core 3.1 и 5.0. Если вы запустите .NET Core, включив —version переключатель, вы увидите, что используется последняя версия.

  

  Теперь создайте файл global.json в текущем каталоге (домашнем каталоге) и задайте версию явным образом с помощью средства cat, как показано ниже. Затем проверьте версию еще раз. Теперь здесь отображается точная версия пакета SDK, которую вы поместили в файл global.json .

  

  Это важно знать при выполнении некоторых команд пакета SDK, таких как создание приложения с помощью команды .NET Core new . Однако это не нужно делать при использовании средств dotnet-dump и dotnet-gcdump.

  Пакет SDK для .NET Core устанавливает последнюю версию средств независимо от выбранного пакета SDK. Например, если вы выполнили команды для установки средств dotnet-dump, dotnet-gcdump и dotnet-symbol для пакета SDK для .NET Core 3.1, будут загружены и установлены последние версии этих средств, как показано на следующем снимке экрана (где установлена версия 5 средств для dotnet-dump и dotnet-gcdump).

  

  Следующие статьи являются отличными ресурсами для получения дополнительных сведений о средствах .NET Core:

  • Управление средствами .NET
  • dotnet tool install

  Выбор используемой версии среды выполнения отличается от выбора версии пакета SDK. Если вы хотите использовать определенную версию среды выполнения .NET, используйте параметр —fx-version , как описано в этой статье.

  Дальнейшие действия

  Теперь вы готовы приступить к устранению неполадок. В лабораториях вы узнаете, как использовать средства, описанные здесь, для устранения неполадок.

  Обратная связь

  Были ли сведения на этой странице полезными?

  Похожие публикации:

  1. Где размещать резюме программисту
  2. Где хранятся временные таблицы sql server
  3. Как работать с платформой
  4. Как удалить cookie php