Инструмент мониторинга/профилирования производительности Go: go tool pprof

如果我们想要在某一时刻停止CPU使用情况记录操作，就需要调用下面这个函数：

func stopCPUProfile() {
	if *cpuProfile != "" {
		pprof.StopCPUProfile() // 把记录的概要信息写到已指定的文件
	}
}
 

В этой функции нет кода для операции записи профиля ЦП. Фактически система выполнения записывает выборочные данные в профиль ЦП 100 раз в секунду после начала операции записи использования ЦП.pprof.StopCPUProfileФункция останавливает операцию выборки, устанавливая частоту выборки использования ЦП на 0. И только после того, как все записи об использовании ЦП будут записаны в профиль ЦП,pprof.StopCPUProfileфункция выйдет. Это обеспечивает целостность профиля ЦП.

профиль памяти

Профили памяти используются для сохранения использования памяти во время выполнения пользовательской программы. Упомянутое здесь использование памяти на самом деле является выделением памяти кучи во время выполнения программы. Система времени выполнения языка Go записывает все выделения памяти в куче во время выполнения пользовательской программы. Независимо от того, увеличилось ли количество используемых байтов памяти кучи во время выборки, анализатор будет производить выборку байтов до тех пор, пока выделено достаточное количество байтов. Вот как включить ведение журнала использования памяти:

func startMemProfile() {
	if *memProfile != "" && *memProfileRate > 0 {
		runtime.MemProfileRate = *memProfileRate
	}
}
 

Как мы видим, способ включения логирования использования памяти очень прост. в функцииstartMemProfile, только в*memProfileа также*memProfileRateПоследующие операции будут выполняться только тогда, когда значение допустимо.*memProfileСмысл - абсолютный путь к профилю памяти.*memProfileRateИмеется в виду интервал выборки анализатора, в байтах. Когда мы присваиваем это значение переменной типа intruntime.MemProfileRate, это означает, что профилировщик будет производить выборку использования памяти после каждого выделения указанного количества байтов. На самом деле, даже если мы не даемruntime.MemProfileRateТакже будет выполняться назначение переменных, операция выборки использования памяти. Эта операция выборки начинается в начале программы пользователя и продолжается до конца программы пользователя.runtime.MemProfileRateЗначение переменной по умолчанию равно512 * 1024, что составляет 512 Кбайт. Только когда мы явно устанавливаем0назначатьruntime.MemProfileRateПосле переменной операция выборки отменяется.

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

func stopMemProfile() {
	if *memProfile != "" {
		f, err := os.Create(*memProfile)
		if err != nil {
			fmt.Fprintf(os.Stderr, "Can not create mem profile output file: %s", err)
			return
		}
		if err = pprof.WriteHeapProfile(f); err != nil {
			fmt.Fprintf(os.Stderr, "Can not write %s: %s", *memProfile, err)
		}
		f.Close()
	}
}
 

Из названия функцииstopMemProfileФункция функции состоит в том, чтобы остановить операцию выборки использования памяти. Однако он ничего не делает, кроме сохранения выборочных данных в профиль памяти. существуетstopMemProfileфункцию, мы вызываем функциюpprof.WriteHeapProfile, с экземпляром файла, представляющим профиль памяти в качестве аргумента. еслиpprof.WriteHeapProfileФункция не возвращает ошибку, указывающую, что данные были записаны в профиль памяти.

Обратите внимание, что программы, которые осуществляют выборку использования памяти, предполагают, что интервал выборки является постоянным в течение продолжительности пользовательской программы и равенruntime.MemProfileRateТекущее значение переменной. Следовательно, мы должны изменить интервал выборки памяти в нашей программе только один раз и как можно раньше. Например, измените его в начале основной функции исходного файла команды.

Профиль блокировки программы

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

func startBlockProfile() {
	if *blockProfile != "" && *blockProfileRate > 0 {
		runtime.SetBlockProfileRate(*blockProfileRate)
	}
}
 

Аналогично включению ведения журнала использования памяти в функцииstartBlockProfileв, когда*blockProfileа также*blockProfileRateКогда значение допустимо, мы устанавливаем интервал выборки для событий блокировки Goroutine.*blockProfileозначает абсолютный путь к профилю блокировки программы.*blockProfileRateИмеется в виду интервал выборки анализатора, единица измерения – раз. функцияruntime.SetBlockProfileRateЕдинственный параметр имеет тип int. Это означает, что профилировщик будет отбирать события блокировки Goroutine каждые несколько раз, когда они происходят. Если мы не используем явноruntime.SetBlockProfileRateФункция устанавливает интервал выборки, тогда интервал выборки равен 1. То есть по умолчанию профилировщик будет производить выборку каждый раз, когда происходит событие блокировки Goroutine. Подобно записям об использовании памяти, система выполнения отбирает события блокировки Goroutine во время выполнения пользовательской программы. Однако если мы пройдемruntime.SetBlockProfileRateФункция устанавливает этот интервал выборки равным0или отрицательное, то операция выборки будет отменена.

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

func stopBlockProfile() {
	if *blockProfile != "" && *blockProfileRate >= 0 {
		f, err := os.Create(*blockProfile)
		if err != nil {
			fmt.Fprintf(os.Stderr, "Can not create block profile output file: %s", err)
			return
		}
		if err = pprof.Lookup("block").WriteTo(f, 0); err != nil {
			fmt.Fprintf(os.Stderr, "Can not write %s: %s", *blockProfile, err)
		}
		f.Close()
	}
}
 

После создания профиля блокировки программ,stopBlockProfileфункция сначала передаст функциюpprof.LookupПолучить запись об использовании памяти, хранящуюся в памяти времени выполнения, и вызвать записанный экземпляр.WriteToспособ записи записей в файл.

больше профилей

мы можем пройтиpprof.LookupФункция извлекает более широкий набор выборочных записей. Следующая таблица:

Таблица 0-20 Записи, которые можно получить с помощью функции pprof.Lookup

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

Мы знаем, что во время работы пользовательской программы различные состояния постоянно меняются. Особенно для последних двух записей, с увеличением времени выборки количество элементов записи будет продолжать расти. Для первых двух записей «goroutine» и «threadcreate», если создается новая активная goroutine или создается новый системный поток, количество записей также будет увеличиваться. Поэтому исполняющая система языка Go сначала оценит количество элементов записи при выборке записей из памяти. Если между предполагаемым количеством записей и получением записей создается новая запись, система выполнения попытается повторно получить все записи. Кроме того, система выполнения использует срезы для загрузки всех записей. Если текущий используемый срез не содержит всех записей, система среды выполнения создаст больший срез на основе текущего общего количества записей и попытается снова загрузить все записи. Пока этот фрагмент не станет достаточно большим, чтобы вместить все записи. Однако, если записи растут слишком быстро, системе выполнения придется продолжать попытки. Это может привести к чрезмерным затратам времени. Для первых двух записей «goroutine» и «threadcreate» размер среза, созданного системой выполнения, равен общему количеству элементов текущей записи плюс 10. Для первых двух записей «куча» и «блок» размер среза, созданного системой выполнения, равен общему количеству элементов текущей записи плюс 50. Хотя вероятность описанной выше ситуации может быть не слишком высока, если для получения вышеуказанных записей для некоторых пользовательских программ с высокой степенью параллелизма требуется слишком много времени, мы можем сначала проверить такие причины. На самом деле упомянутое выше Этот тип операции записи больше подходит для определения состояния пользовательских программ с высокой степенью параллелизма.

Мы можем вывести четыре типа записей в файл с помощью следующей функции.

func SaveProfile(workDir string, profileName string, ptype ProfileType, debug int) {
	absWorkDir := getAbsFilePath(workDir)
	if profileName == "" {
		profileName = string(ptype)
	}
	profilePath := filepath.Join(absWorkDir, profileName)
	f, err := os.Create(profilePath)
	if err != nil {
		fmt.Fprintf(os.Stderr, "Can not create profile output file: %s", err)
		return
	}
	if err = pprof.Lookup(string(ptype)).WriteTo(f, debug); err != nil {
		fmt.Fprintf(os.Stderr, "Can not write %s: %s", profilePath, err)
	}
	f.Close()
}
 

функцияSaveProfileЕсть четыре параметра. Первый параметр — это каталог, в котором хранится профиль. Второй параметр — это имя профиля. Третий параметр — тип профиля. Среди них типProfileTypeПросто псевдоним для строкового типа. Это необходимо для ограничения его стоимости. Его значение должно быть одним из «goroutine», «threadcreate», «heap» или «block». Теперь сосредоточимся на четвертом параметре. параметрdebugУправляет уровнем детализации информации в профиле. Этот параметр также передается в структуруpprof.Profileметод указателяWriteToвторой параметр . а такжеpprof.ProfileУказатель на экземпляр структуры используется функциейpprof.Lookupпроизводить. Посмотрим, как значение параметра debug соотносится с содержимым записи, записываемой в профиль.

Таблица 0-21 Влияние отладки параметра на содержимое профиля

Из вышеприведенной таблицы видно, что приdebugменьше или равно0, система выполнения записывает в профиль только базовую информацию из каждой записи. Основная информация о записи состоит только из адреса памяти в шестнадцатеричном формате записи в стеке вызовов.debugЧем больше значение , тем больше информации мы можем получить из профиля. но,go tool pprofКоманды игнорируют дополнительную информацию помимо основной информации. Фактически, система выполнения записывает дополнительную информацию в профиль со знаком «#» в крайнем левом углу, чтобы обозначить текущую строку комментария к поведению. Из-за этого префиксаgo tool pprofкоманда пропустит синтаксический анализ этой дополнительной информации. Одно исключение из этого, когдаdebugбольше или равно2В то время запись горутины не добавляет информацию на основе базовой информации, а полностью записывает информацию о состоянии и информацию о стеке вызовов каждой активной горутины в легко читаемом виде. Кроме того, в крайнем левом углу всех строк нет префикса «#». Очевидно, что этот профиль не может бытьgo tool pprofразбор команды. Но это будет более интуитивно понятно и полезно для нас.

До сих пор мы ввели использование пакетов кода стандартной библиотеки.runtimeа такжеruntime/pprofВсе методы создания профилей для программ в формате . Весь код в приведенном выше примере хранится в пакете кода проекта goc2p.basic/profсередина. пакет кодаbasic/profЭти программы очень просты в использовании. Однако, поскольку язык Go в настоящее время не имеет API (интерфейс прикладной программы), аналогичного хуку выключения (Shutdown Hook), пакет кодаbasic/profПрограммы в настоящее время могут использоваться только интрузивным способом.

инструмент pprof

Мы упоминали в предыдущем подразделе, что любойgo toolСпециальные инструменты, указанные в открывающих командах Go, хранятся в каталоге $GOROOT/pkg/tool/$GOOS_$GOARCH/. Мы называем этот каталог каталогом инструментов Go. В отличие от других специальных инструментов, инструмент pprof написан не на Go, а на Perl. (Perl — динамический интерпретируемый язык программирования общего назначения.) В отличие от Go, Perl может напрямую читать исходный код и запускать его. Следовательно,pprofФайлы исходного кода для инструментов хранятся непосредственно в каталоге инструментов Go. Для других инструментов Go все исполняемые файлы, существующие в этом каталоге, компилируются и генерируются. Мы можем напрямую открыть исходный файл pprof инструмента pprof в каталоге инструментов Go с помощью любого инструмента для просмотра текста. На самом деле этот файл с исходным кодом скопирован из открытого проекта gperftools, инициированного Google. В этот проект включено множество полезных инструментов. Эти инструменты могут помочь разработчикам создавать более надежные приложения. pprof — один из таких очень полезных инструментов.

потому чтоpprofИнструмент написан на языке Perl, поэтому выполнитеgo tool pprofПредпосылкой для команды является то, что язык Perl должен быть установлен в текущей среде.Рекомендуемый номер версии 5.x. Метод установки языка Perl здесь не описывается, читатель может найти этот метод и установить его самостоятельно. После установки языка Perl мы можем войти в каталог инструментов Go в терминале командной строки и выполнить командуperl pprof. Он работает с нами для выполнения в любом каталогеgo tool pprofЭффект команды одинаково. Конечно, если вы хотитеgo tool pprofКоманды могут выполняться в любом каталоге.Сначала нам нужно установить переменные среды, связанные с языком Go.

Мы обсудили в этом подразделе,go tool pprofКоманда анализирует указанный профиль и позволяет нам в интерактивном режиме получить доступ к информации в нем. Но одного профиля недостаточно, нам нужен еще и источник информации в профиле - исполняемый файл исходного кода команды. В конце концов, информация в профиле является результатом выборки пользовательской программы во время выполнения. Исполняемая программа на языке Go, которую можно запустить, может быть только исполняемым файлом, сгенерированным после компиляции файла исходного кода команды. Поэтому для демонстрацииgo tool pprofИспользование команды, мы также создаем или преобразуем исходный файл команды. В пакете кода нашего проекта goc2p есть исходный файл команды с именем showpds.go. Этот исходный файл команды используется для анализа зависимостей указанного пакета кода и печати этих зависимостей на стандартном устройстве вывода. Причина выбора этого исходного файла команд заключается в том, что мы можем контролировать время выполнения этого исходного файла команд, изменяя указанный пакет кода. Различные пакеты кода могут иметь разное количество прямых и косвенных зависимостей. Пакет кода с большим количеством зависимостей приведет к тому, что исходному файлу команды потребуется больше времени для разрешения его зависимостей. Чем дольше работает исходный файл команды, тем более значимую информацию в профиле мы получаем. Чтобы сгенерировать профиль, нам нужно немного изменить исходный файл команды. Сначала нам нужно импортировать пакет кода в этот файлbasic/prof. Затем нам нужно добавить строку кода в начало его основной функции.prof.Start(). Эта строка кода предназначена для проверки соответствующего флага и включения или установки соответствующей операции записи использования, когда флаг действителен. Наконец, нам также нужно добавить строку кода в блок отложенной функции main.prof.Stop(). Смысл этой строки кода в том, чтобы получить выборочные данные открытых записей и записать их в указанный профиль. С помощью этих трех шагов мы прикрепили возможность создания профиля среды выполнения к исходному файлу команды. Чтобы включить эти функции, мне также нужно выполнитьgo runКогда команда запускает исходный файл команды, добавьте соответствующую отметку. пакет кодаbasic/profДопустимые теги для программ перечислены в следующей таблице.

Таблица 0-22 Допустимые теги для API пакета кода basic/prof

Ниже мы используемgo runКоманда запускает измененный исходный файл команды showpds.go. Пример выглядит следующим образом:

hc@ubt:~/golang/goc2p$ mkdir pprof
hc@ubt:~/golang/goc2p$ cd helper/pds
hc@ubt:~/golang/goc2p/helper/pds$ go run showpds.go -p="runtime" cpuprofile="../../../pprof/cpu.out" -blockprofile="../../../pprof/block.out" -blockprofilerate=1 -memprofile="../../../pprof/mem.out" -memprofilerate=10
The package node of \'runtime\': {/usr/local/go/src/pkg/ runtime [] [] false}
The dependency structure of package \'runtime\':
runtime->unsafe
 

В приведенном выше примере мы использовали все пары пакетов кода.basic/profДопустимая разметка API. Кроме того, отметьте-pОн действителен для исходного файла команды showpds.go. Его смысл заключается в указании пути импорта пакета кода, зависимости которого должны быть разрешены.

Теперь давайте посмотрим на подкаталог pprof в каталоге проекта goc2p:

hc@ubt:~/golang/goc2p/helper/pds$ ls ../../../pprof
block.out  cpu.out  mem.out
 

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

Что ж, все готово к работе. Теперь давайте посмотримgo tool pprofкоманда может делать что угодно. Во-первых, давайте скомпилируем исходный файл команды showpds.go.

hc@ubt:~/golang/goc2p/helper/pds$ go build showpds.go
hc@ubt:~/golang/goc2p/helper/pds$ ls
showpds showpds.go
 

Затем нам нужно подготовить профиль. Стандартный пакет кода библиотекиruntimeСуществует очень мало зависимостей, что делает исполняемые ShowPDS, выполняемые до завершения в течение очень короткого времени. Мы сказали до этого, чем дольше проходит программа, тем лучше. Поэтому нам нужно найти код кода с большим количеством прямых и косвенных зависимостей. Коллеги, которые сделали разработку системы веб-приложений, знают, что внутренняя программа системы веб-приложений может иметь много зависимостей, будь то кодовая база или другие ресурсы. Согласно нашей интуиции, это должно быть случай в мире ухода. В стандартной библиотеке языка Go, кодовой пакетnet/httpОн специально используется для предоставления различной поддержки API для разработки системы веб-приложений. Мы используем этот пакет кода для создания необходимого профиля.

hc@ubt:~/golang/goc2p/helper/pds$ ./showpds -p="net/http" -cpuprofile="../../../pprof/cpu.out" -blockprofile="../../../pprof/block.out" -blockprofilerate=1 -memprofile="../../../pprof/mem.out" -memprofilerate=10
 

Стандартный пакет кода библиотекиnet/httpЕсть много зависимостей. Из-за этого я игнорирую весь вывод. Читатели могут попробовать приведенную выше команду самостоятельно. Мы сгенерировали все профили, которые смогли создать за один раз, в качестве резервной копии. Этот профиль сохраняется в каталоге pprof проекта goc2p. Если перед выполнением вышеуказанной команды каталог pprof отсутствует, команда сообщит об ошибке. Таким образом, читатели должны сначала создать этот каталог.

Теперь выполняем его с исполняемым файлом showpds и профилем процессора cpu.out в каталоге pprof в качестве параметраgo tool pprofЗаказ. На самом деле мы проходимgo tool pprofКоманда входит в интерфейс интерактивного режима инструмента pprof.

hc@ubt:~/golang/goc2p/helper/pds$ go tool pprof showpds ../../../pprof/cpu.out
Welcome to pprof!  For help, type \'help\'.
(pprof)
 

Мы можем просмотреть профиль, введя некоторые команды после приглашения «(pprof)». Команды, поддерживаемые инструментом pprof в интерактивном режиме, следующие.

Табл. 0-23 Команды, поддерживаемые инструментом pprof в интерактивном режиме

Большинство команд в приведенной выше таблице (кроме help и quit) могут добавлять один или несколько аргументов ко всем своим аргументам и меткам, чтобы указать имя функции или метода, которые вы хотите игнорировать при отображении. Нам нужно префикс таких параметров со знаком минус "-", а несколько параметров должны быть разделены пробелами. Конечно, мы также можем заменить имя функции или метода регулярным выражением. После добавления этих ограничений любые образцы в стеке вызовов, содержащие функции или методы с именами, соответствующими таким параметрам, не будут отображаться в выводе команды. Ниже мы опишем эти команды одну за другой.

команда gv

Для использования команды gv см. следующий пример:

hc@ubt:~/golang/goc2p/helper/pds$ go tool pprof showpds ../../../pprof/cpu.out
Welcome to pprof!  For help, type \'help\'.
(pprof) gv
Total: 101 samples
sh: 1: dot: not found
go tool pprof: signal: broken pipe
 

Где "(pprof)" - подсказка инструмента pprof в интерактивном режиме.

Из вывода мы видим, что команда gv была выполнена неправильно. Причина в том, что командная точка не найдена. После расследования эта команда принадлежит программному обеспечению с открытым исходным кодом Graphviz. Основная функция Graphviz — визуализация графиков. Мы можем использовать командуsudo apt-get install graphvizдля установки этого программного обеспечения. Обратите внимание, что приведенная выше команда доступна только для дистрибутива Debian Linux и его производных. Если вы используете дистрибутив Redhat Linux и его производные, вы можете использовать команду «yum install graphviz» для установки Graphviz. После установки Graphviz снова выполним команду gv.

(pprof) gv
Total: 101 samples
gv -scale 0
(pprof) sh: 1: gv: not found
 

Теперь вывод говорит нам, что команда gv не найдена. gv - это программное обеспечение с открытым исходным кодом в проекте разработки свободного программного обеспечения GNU (GNU's Not Unix), которое используется для просмотра PDF-документов в графическом виде. Устанавливаем так же. В дистрибутиве Linux Debian и его производных выполните командуsudo apt-get install gv, в дистрибутиве Redhat Linux и его производных выполните командуyum install gv. После установки программного обеспечения gv снова выполняем команду gv. В операционной системе Linux, работающей с программным обеспечением с графическим интерфейсом, появится такое окно. Рисунок 5-3.

Рисунок 0-3 Результат выполнения команды gv утилиты pprof

Мы видим, что в верхней части сводного графика отображается некоторая основная информация. где «showpds» — это исполняемый файл, который мы использовали для создания профиля. Это также источник контента в профиле. Число 23 после «Всего выборок:» означает, что анализатор произвел в общей сложности 23 выборки во время выполнения этой программы. Мы уже знаем, что выборка использования ЦП происходит каждые 10 миллисекунд. Таким образом, выборка 23 раза означает, что процессорное время, затрачиваемое на выполнение программы, приблизительно равно10毫秒 * 23 = 0.23秒. Поскольку мы не добавили параметр focus для ограничения отображаемого содержимого после команды gv, в поле «Фокусировка Число после «on:» также равно 23. Именно по этой причине числа в следующих двух строках информации равны 0. Читатели могут проверить случай добавления параметра фокуса после команды gv, например:gv ShowDepStruct. В следующем описании функции и методы мы будем называть функциями.

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

Во-первых, читатели должны разобраться с двумя похожими, но разными понятиями, а именно: локальные выборочные подсчеты и кумулятивные выборочные подсчеты. Смысл локального счетчика выборки — это количество раз, когда текущая функция непосредственно появляется в выборке. Значение кумулятивного счетчика выборки — это количество раз, которое текущая функция и текущая функция прямо или косвенно вызывает при выборке. Поэтому есть такой сценарий: для функции ее локальный счетчик выборок равен 0. Потому что он не появился непосредственно в выборке. Однако, поскольку это прямо или косвенно называется функциональностью непосредственно в выборке, совокупный счетчик выборки этой функции будет высоким. Функция mi.main в нашем примере приведена в качестве примера. Поскольку функция main.main не появлялась непосредственно во всех выборках, ее локальный счетчик выборок был равен 0. Но поскольку это функция входа в исходный файл команды, другие функции в программе вызываются прямо или косвенно. Поэтому его кумулятивное количество выборок является самым высоким среди всех функций, достигая 22. Обратите внимание, что независимо от того, является ли локальный счетчик выборки или кумулятивный счетчик выборки, функция не вычисляет свой собственный вызов. Функция вызывает рекурсивные вызовы собственных вызовов.

Наконец, следует отметить, что направленный отрезок на графике представляет вызывающую связь между функциями. Число рядом с направленным сегментом — это количество вызовов функции в начале сегмента к функции в конце сегмента. Упомянутое здесь количество вызовов фактически основано на совокупном количестве выборок функции. Более конкретно, если существует направленный отрезок от функции A к функции B и число рядом с ним равно 10, то это означает, что 10 отсчетов в совокупном отсчете выборки функции B вызваны прямыми вызовами функции A к функции B. , вызванный. Также по этой причине количество вызовов функции A к функции B должно быть меньше или равно совокупному количеству выборок функции B.

До сих пор мы объясняли все элементы схемы, и я полагаю, что читатель смог ее понять. Итак, как мы можем проанализировать программу с помощью схемы схемы?

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

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

Мы можем рассчитать время, необходимое для выполнения функции, по ее совокупному количеству выборок. Чем выше совокупное количество выборок функции, тем больше процессорного времени требуется для ее вызова. В частности, мы можем умножить интервал выборки ЦП (10 мс) на совокупное количество выборок функции, чтобы получить фактическое время, которое потребовалось. Хотя это фактическое время с точностью до 10 миллисекунд, этого достаточно для анализа производительности программы. Даже если совокупное количество выборок функции велико, мы не можем решить, что сама функция проблематична. Мы должны следить за потоком и находить функции, которые являются наиболее ресурсоемкими среди функций, вызываемых прямо или косвенно этой функцией. На самом деле такой поиск прост, потому что у нас уже есть схематическая диаграмма. На графике вызова функции функция с большим совокупным количеством выборок имеет большую площадь узла (прямоугольник на графике). Однако есть исключения, то есть входная функция программы. Вообще говоря, во всей связи вызова функции существует не более одной функции в том же направлении рядом с начальной позицией и соединенной с направленным отрезком линии, которую можно назвать функцией входа. Независимо от их совокупного количества выборок, площадь узла, которому они принадлежат, является наименьшей в графе вызовов функций. Поскольку почти все функции, появляющиеся в графе выборок и вызовов функций, происходят от прямых или косвенных вызовов входных функций, кумулятивное число выборок входных функций должно быть наибольшим среди них. В общем, нам не нужно заботиться о значении счетчика функции входа, поэтому нет необходимости использовать большую площадь узлов в графе вызовов функций, чтобы выделить их. На рисунке 5-3 функцияruntime.mainа такжеmain.mainможно рассматривать как входные функции. Кроме того, на графике отношения вызовов функций толщина направленного сегмента линии также отражает размер соответствующего счетчика вызовов.

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

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

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

3. Только с точки зрения подсчета вызовов мы не можем судить, берет ли функция на себя слишком много обязанностей или содержит слишком много логики управления потоком. Однако мы можем использовать подсчет вызовов в качестве помощи в обнаружении проблем. Например, если на основе анализа в Процессе 1 и Процессе 2 мы подозреваем, что в функцииBВ вызываемой функции могут быть проблемы с производительностью, и мы также обнаружили, что функцияAпарная функцияBКоличество вызовов также очень велико, тогда мы должны подумать о функцииBЧастые появления в выборках могут быть вызваны функциейAпарная функцияBиз-за частых звонков. В этом случае сначала следует рассмотреть функциюAкод в , проверьте, не содержит ли он слишком много пар функцийBнеобоснованный звонок. Если есть необоснованные вызовы, мы должны переделать эту часть кода. В дополнение к этому мы также можем определить некоторые небольшие проблемы на основе количества вызовов. Например, если функция находится в том же пакете кода, что и все вызывающие ее функции, то нам следует рассмотреть возможность установки прав доступа вызываемой функции как закрытых внутри пакета. Если все вызовы функции исходят из одной и той же функции, мы можем рассмотреть возможность объединения двух функций в соответствии с принципом единой ответственности. Читатель, возможно, заметил, что это противоречит одному из предложений в Процессе 1. По сути, это тоже стратегия отложенной оптимизации.

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

В описании этих процессов анализа мы много раз упоминали команду списка. Теперь давайте объясним это. Сначала рассмотрим пример:

(pprof) list ShowDepStruct
Total: 23 samples
ROUTINE ====================== main.ShowDepStruct in /home/hc/golang/goc2p
	/src/helper/pds/showpds.go
     0     20 Total samples (flat / cumulative)
     .      .   44: 	}
     .      .   45: 	fmt.Printf("The dependency structure of package \'%s\':\n",
	 pkgImportPath)
     .      .   46: 	ShowDepStruct(pn, "")
     .      .   47: }
     .      .   48: 
---
     .      .   49: func ShowDepStruct(pnode *pkgtool.PkgNode, prefix string) {
     .      .   50: 	var buf bytes.Buffer
     .      .   51: 	buf.WriteString(prefix)
     .      .   52: 	importPath := pnode.ImportPath()
     .      2   53: 	buf.WriteString(importPath)
     .      1   54: 	deps := pnode.Deps()
     .      .   55: 	//fmt.Printf("P_NODE: \'%s\', DEP_LEN: %d\n", importPath,
	 len(deps))
     .      .   56: 	if len(deps) == 0 {
     .      5   57: 		fmt.Printf("%s\n", buf.String())
     .      .   58: 		return
     .      .   59: 	}
     .      .   60: 	buf.WriteString(ARROWS)
     .      .   61: 	for _, v := range deps {
     .     12   62: 		ShowDepStruct(v, buf.String())
     .      .   63: 	}
     .      .   64: }
---
     .      .   65: 
     .      .   66: func getPkgImportPath() string {
     .      .   67: 	if len(pkgImportPathFlag) > 0 {
     .      .   68: 		return pkgImportPathFlag
     .      .   69: 	}
(pprof) 
 

Мы ввели команду в интерактивном интерфейсе инструмента pproflist ShowDepStructПолучил много продукции после этого. Среди них ShowDepStruct — это значение параметра подпрограммы_regexp. Первая строка вывода сообщает нам, что в профиле ЦП 23 выборки. Это то же самое, что мы видели ранее, когда объясняли команду gv. Вторая строка вывода показывает, что функция, которая соответствует значению предоставленного нами регулярного выражения программы (то есть параметру подпрограммы_regexp), равнаmain.ShowDepStruct, а абсолютный путь к исходному файлу, в котором находится эта функция, — /home/hc/golang/goc2p/src/helper/pds/showpds.go. Третья строка в выводе говорит нам, что вmain.ShowDepStructСумма локальных выборок для кода в теле функции равна 0, а сумма совокупных выборок равна 20. В крайних правых круглых скобках в третьей строке flat представляет количество локальных выборок, а cumulative — совокупное количество выборок. Это намек на то, что означают два числа в крайнем левом углу строки (то есть 0 и 20). Начиная с четвертой строки выводимой информации идет перехват кода в вышеуказанном файле исходного кода, который содержитmain.ShowDepStructИсходный код функции. Команда list добавляет соответствующие номера строк слева от этих кодов, что облегчает поиск кодов. Кроме того, в соответствующей позиции слева от номера строки кода отображается локальное количество выборок и совокупное количество выборок для каждой строки кода. Если счетчик равен 0, вместо этого используйте английскую точку «.». Это делает очень удобным поиск строк кода, в которых существует значение счетчика.