Статистика и события времени исполнения в Golang

Среда исполнения (runtime) предоставляет пользователям статистику и отчеты о внутренних событиях для диагностики проблем производительности и использования на уровне времени исполнения.

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

• runtime.ReadMemStats сообщает о метриках, связанных с выделением кучи и сборкой мусора. Статистика памяти полезна для мониторинга того, сколько ресурсов памяти потребляет процесс, может ли процесс эффективно использовать память, и выявлять утечки памяти.
• debug.ReadGCStats читает статистику о сборке мусора. Полезно посмотреть, сколько ресурсов расходуется на паузы в GC. Он также сообщает временную шкалу пауз сборщика мусора и процентили времени паузы.
• debug.Stack возвращает текущую трассировку стека. Трассировка стека полезна, чтобы увидеть, сколько в настоящий момент запущено goroutines, что они делают, и заблокированы они или нет.
• debug.WriteHeapDump приостанавливает выполнение всех goroutines и позволяет выгрузить кучу в файл. Дамп кучи - это снимок памяти процесса Go в данный момент времени. Он содержит все выделенные объекты, а также процедуры, финализаторы и многое другое.
• runtime.NumGoroutine возвращает количество текущих goroutines. Это значение можно отслеживать, чтобы увидеть, достаточно ли используется goroutines, или для обнаружения утечек goroutines.

Трассировщик исполнения

Go поставляется с трассировщиком исполнения времени исполнения для захвата широкого спектра событий во время исполнения. Планирование, системный вызов, сборка мусора, размер кучи и другие события собираются во время исполнения и доступны для визуализации go tool trace. Трассировщик исполнения является инструментом для выявления задержек и проблем с использованием ресурсов. Вы можете проверить, насколько эффективно используется ЦП, и когда сетевые или системные вызовы являются причиной прерывания для goroutines.

Трассировщик полезен для:

• Понимания, как выполняются ваши программы.
• Ознакомления с некоторыми основными событиями среды исполнения, такими как GC.
• Выявления плохо распараллеленного исполнения.

Тем не менее, он не подходит для выявления горячих точек, таких как анализ причин чрезмерного использования памяти или ЦП. Вместо этого сначала используйте инструменты профилирования для их решения.

Выше визуализация go tool trace показывает, что выполнение началось нормально, а затем оно стало сериализованным. Это предполагает, что может быть конфликт блокировки для общего ресурса, который создает узкое место.

GODEBUG

Среда исполнения также генерирует события и информацию, если переменная среды GODEBUG установлена ​​соответствующим образом.

• GODEBUG=gctrace=1 печатает события сборщика мусора в каждой коллекции, суммируя объем собранной памяти и продолжительность паузы.
• GODEBUG=schedtrace=X печатает события планирования каждые X миллисекунд.

Переменная окружения GODEBUG может использоваться для отключения использования расширений набора команд в стандартной библиотеке и библиотеки времени исполнения (runtime).

• GODEBUG=cpu.all=off отключает использование всех необязательных расширений набора команд.
• GODEBUG=cpu.extension=off запрещает использование инструкций из указанного расширения набора команд. extension - это имя в нижнем регистре для расширения набора команд, например, sse41 или avx.

---

Читайте также:

• Профилирование в Golang, профили runtime/pprof
• Отладка в Golang
• Трассировка в Golang

Канал в Телеграм

Релиз Go 1.14: runtime и компилятор

Runtime (среда времени выполнения)

Релиз Go 1.14 улучшает производительность большинства применений defer, что приводит к почти нулевым издержкам по сравнению с непосредственным вызовом отложенной функции. В результате, теперь defer можно использовать в коде, критичном к производительности, без лишних проблем.

Goroutines теперь асинхронно вытесняются. В результате циклы без вызовов функций больше не могут заблокировать планировщик или существенно задержать сборку мусора. Это поддерживается на всех платформах, кроме windows/arm, darwin/arm, js/wasm и plan9/*.

Следствием реализации вытеснения является то, что в системах Unix, включая системы Linux и macOS, программы, собранные (build) с Go 1.14, будут получать больше сигналов, чем программы, собранные (build) с более ранними релизами. Это означает, что программы, использующие такие пакеты, как syscall или golang.org/x/sys/unix, увидят, что более медленные системные вызовы завершаются с ошибками EINTR. Этим программам придется каким-то образом обрабатывать эти ошибки, скорее всего, повторяя цикл, чтобы повторить системный вызов.

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

Внутренние таймеры, используемые time.After, time.Tick, net.Conn.SetDeadline и схожие, более эффективны, с меньшим количеством конфликтов блокировки и меньшим количеством переключений контекста. Это улучшение производительности, которое не должно вызывать видимых изменений.

Компилятор

В релизе Go 1.14 добавлена ​​опция -d=checkptr в качестве параметра времени компиляции для добавления инструментария для проверки того, что код Go соответствует unsafe.Pointer правилам безопасности динамически. Эта опция включается по умолчанию (кроме Windows) с флагами -race или -msan и может быть отключена с -gcflags=all=-d=checkptr=0. В частности, -d=checkptr проверяет следующее:

1. При преобразовании unsafe.Pointer в *T результирующий указатель должен быть выровнен соответствующим образом для T.
2. Если результат арифметики указателя указывает на объект кучи (heap) Go, один из операндов с типом unsafe.Pointer должен указывать на тот же объект.

Использование -d=checkptr в настоящее время не рекомендуется в Windows, потому что это вызывает ложные предупреждения в стандартной библиотеке.

Компилятор теперь может генерировать машиночитаемые журналы ключевых оптимизаций, используя флаг -json, включая встраивание (inlining), escape-анализ, исключение bounds-check (исключение проверки границ) и nil-check.

Детальный escape-анализ (-m=2) теперь снова работает. Ранее он был исключен из новой реализации escape-анализа в предыдущем релизе.

Все символы Go в двоичных файлах macOS теперь начинаются с подчеркивания, следуя соглашениям платформы.

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

Исключение проверки границ теперь использует информацию из создания среза и может исключать проверки для индексов с типами, меньшими, чем int.

---

Читайте также:

• Релиз Go 1.14: изменения в языке и его портах
• Релиз Go 1.14: инструменты, команда go
• Go 1.13 заметки о релизе

Канал в Телеграм

Go FAQ: Можно ли прекратить жалобы компилятора на неиспользованную переменную/импорт?

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

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

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

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

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

import "unused"

// Это объявление помечает импорт как использованный 
// путем ссылки на элемент из пакета.
var _ = unused.Item  // TODO: Удалить перед коммитом!

func main() {
    debugData := debug.Profile()
    _ = debugData // Использовано только в ходе отладки.
    ....
}

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

---

Читайте также:

• Эффективный Go: пустой идентификатор
• Эффективный Go: пустой идентификатор в импорте и переменных
• Эффективный Go

Go FAQ: Как реализована runtime поддержка в Go?

Опять же из-за проблем с загрузкой, упоминавшихся в предыдущем посте, runtime код изначально был написан в основном на C (с небольшим количеством ассемблера), но с тех пор он был переведен на Go (за исключением некоторых битов ассемблера). Поддержка Gccgo runtime использует glibc. Компилятор gccgo реализует программы с использованием техники, называемой сегментированными стеками, поддерживаемой недавними изменениями в gold linker. Gollvm аналогичным образом построен на соответствующей LLVM инфраструктуре.

---

Читайте также:

• Go FAQ: Есть ли у Go runtime (среда выполнения)?
• Go FAQ: можно ли связать программы на Go с программами на C/C++?
• Go FAQ: Какие компиляторы используются для создания самих Go компиляторов?

Go FAQ: Есть ли у Go runtime (среда выполнения)?

Go имеет обширную библиотеку, которая называется runtime, это часть каждой Go программы. Библиотека runtime реализует сборку мусора, параллелизм, управление стеками и другие важные функции языка Go. Хотя она более центральна для языка, runtime Go аналогична libc библиотеке в языке C.

Однако важно понимать, что среда выполнения (runtime) Go не включает виртуальную машину, например, предоставляемую средой выполнения Java. Программы на Go заранее скомпилированы в машинный код (или JavaScript или WebAssembly, для некоторых вариантов реализации). Таким образом, хотя термин часто используется для описания виртуальной среды, в которой запускается программа, в Go слово “runtime” это просто имя, данное библиотеке, предоставляющей критически важные языковые услуги.

---

Читайте также:

• Основы Go
• Эффективный Go
• Веб-приложение на Go