Анализируйте показатели Go
Ключ-Астром ЕдиныйАгент отслеживает множество показателей, связанных с Go.
Вкладки «Метрики Go» и «Метрики Go HTTP» на странице обзора процесса содержат наиболее важные метрики Go и HTTP. Вкладки «Управляемая память Go», «Сведения о куче» и «Планирование», доступные через вкладку «Дополнительные сведения», дают еще более ценную информацию о производительности вашего приложения на основе Go.
Ключевые метрики
На вкладке «Метрики Go» представлены следующие важные метрики Golang:
- Приостановка: процентная доля сборщика мусора Go по сравнению с общим временем ЦП приложения.
- Куча времени выполнения: объем памяти, используемый или зафиксированный в куче Go, а также время сборки мусора Go.
- Горутины: количество горутин, созданных приложением и инфраструктурой времени выполнения Go.
Метрики HTTP
На вкладке «HTTP-метрики Go» вы можете изучить следующие HTTP-метрики:
- Всего запросов: количество всех запросов, представляющих общий поток трафика.
- Количество ответов HTTP 5xx: количество ответов, которые указывают на повторяющиеся сбои приложений или проблемы с ответами приложений.
- Количество неверных HTTP-шлюзов: количество ответов, указывающих на недопустимые ответы службы, созданные приложением.
- Задержка ответа: среднее время ответа от приложения к клиентам.
Перейти к управляемой памяти
Вкладка управляемая память Go разбивает показатели памяти на различные категории:
- Куча: объем памяти, используемый или зафиксированный в куче времени выполнения Go.
- OffHeap: объем памяти, используемой или зафиксированной во внутренних структурах среды выполнения Go, которые не выделяются из памяти кучи. Структуры данных, используемые в реализации Go Heap, являются примером памяти OffHeap.
- Итого: сумма памяти кучи, OffHeap и стека.
- Стек: объем памяти, используемой или выделенной для динамических стеков Go. Стеки Go используются для выполнения горутин и динамически растут.
Детали кучи
Вкладка «Детали кучи» позволяет глубже изучить анатомию кучи Go.
- Количество объектов Go, выделенных кучей: количество объектов Go, размещенных в куче Go.
- Размер кучи в режиме ожидания: объем памяти, не назначенный куче или стеку. Простаивающая память может быть возвращена операционной системе или сохранена средой выполнения Go для последующего переназначения в кучу или стек.
- Активный размер кучи: объем памяти, который сборщик мусора Go считает активной. Этот показатель накапливает память, оставшуюся после последнего запуска сборщика мусора и выделенную с тех пор.
- Счетчик вызовов сборщика мусора: количество запусков сборщика мусора Go.
Планирование
О планировании горутин
Базовое понимание принципов внутреннего планирования поможет вам прочитать показатели планирования и обнаружить потенциальные аномалии.
Реализация планирования Goroutine имеет дело с тремя центральными типами объектов: M (Machine), P (Processor) и G (Goroutine). Вы можете найти несколько экземпляров этих типов объектов в исходном коде среды выполнения Go. Для простоты Ключ-Астром использует следующие альтернативные термины:
| Срок выполнения Go | Срок действия Ключ-Астром |
|---|---|
| M (Machine) | Worker thread |
| P (Processor) | Scheduling context |
| G (Goroutine) | Goroutine |
Go выполняет горутины в контексте рабочих потоков, полученных из пула собственных потоков операционной системы. Goroutine может быть назначен другому рабочему потоку в любое время, если только среда выполнения. LockOSThread не используется для обеспечения привязки рабочего потока.
Несколько горутин обычно назначаются одному рабочему потоку. Контекст планирования отвечает за совместное планирование горутин. Компилятор Go добавляет код к каждому прологу функции Go, который проверяет, использовала ли выполняемая в данный момент Goroutine свой временной отрезок в 10 миллисекунд. Фактический механизм умело использует защиту стека для принудительного изменения расписания. Если временной интервал превышен, контекст планирования устанавливает следующую горутину для выполнения. До Go 1.14 планирование было полностью совместным, что приводило к проблеме с горутинами, которые не вызывали функции Go и, следовательно, не переносились. Go 1.14 представил механизм, позволяющий упреждающее планирование горутин для обработки этого особого случая.
Каждый набор горутин выполняется рабочим потоком. Выполнение контролируется контекстом планирования. Когда Goroutine записывает большой кусок данных на диск или блокирует ожидание входящего соединения, Goroutine блокируется в системном вызове, и никакие другие Goroutine не планируются. В такой ситуации контекст планирования с другими горутинами назначается другому рабочему потоку, либо припаркованному, либо вновь созданному. Эти горутины не блокируются системным вызовом и могут продолжать выполнение. Следовательно, общее количество рабочих потоков больше, чем количество объектов контекста планирования. После того, как блокирующий вызов возвращается, Goroutine снова назначается контексту планирования. Если назначение не удается, горутин отправляется в глобальную очередь выполнения горутина. Тот же принцип применяется к вызовам cgo (перейти на язык C).
Количество контекстов планирования - это единственный параметр, который вы можете настроить в алгоритме планирования Go. Вы не можете контролировать количество рабочих потоков. Вот почему запись большого объема данных на диск или ожидание входящих соединений не будет блокировать другие Goroutines, которые изначально назначены тому же рабочему потоку. Эти горутины продолжают выполнение своих вновь назначенных рабочих потоков.
Вкладка «Планирование» предоставляет уникальные сведения о планировании Goroutine.
- Счетчик системных вызовов среды выполнения Go: количество системных вызовов, выполненных средой выполнения Go. В это число не входят системные вызовы, выполняемые кодом пользователя.
- Перейти на язык C (cgo) call count: количество вызовов cgo.
- Число припаркованных рабочих потоков: количество рабочих потоков, припаркованных средой выполнения Go. Припаркованный рабочий поток не использует циклы ЦП до тех пор, пока среда выполнения Go не отключит поток.
- Количество неработающих рабочих потоков: количество рабочих потоков, в связанном контексте планирования которых больше нет горутин для выполнения. Когда это происходит, рабочий поток пытается украсть горутины из другого контекста планирования или глобальной очереди выполнения. Если кража не удалась, рабочий поток через какое-то время паркуется. Этот же механизм применяется к сценарию с высокой рабочей нагрузкой. Когда существует неактивный контекст планирования, среда выполнения Go снимает парковку с припаркованного рабочего потока и связывает его с неактивным контекстом планирования. Незапаркованный рабочий поток теперь находится в состоянии «не работает» и начинает кражу Goroutine.
- Количество рабочих потоков: количество потоков операционной системы, созданных для выполнения горутин. Go не завершает рабочие потоки; он сохраняет их в припаркованном состоянии для повторного использования в будущем.
- Размер глобальной очереди выполнения горутин: количество горутин в глобальной очереди выполнения. Горутины помещаются в глобальную очередь выполнения, если рабочий поток, используемый для выполнения системного вызова блокировки, не может получить контекст планирования. Контексты планирования периодически получают горутины из глобальной очереди выполнения.
- Счетчик контекста незанятого планирования: количество контекстов планирования, в которых больше нет горутин для выполнения и для которых получение горутинов из глобальной очереди выполнения или других контекстов планирования не удалось.
