Руководство по устранению неполадок в Голанге

задняя часть Go

Текст ｜ Саньцзан (Тан Чжицзянь)

Когда мы получаем сигнал тревоги от онлайн-сервиса, как нам правильно с ним обращаться? Как найти RootCase при возникновении необъяснимых проблем с производительностью?Диагностика проблем в режиме онлайн всегда затруднена, но мы можем использовать зрелую методологию и цепочку инструментов, чтобы помочь нам быстро найти проблему. Здесь мы делимся с вами на основе нашей внутренней практики.

1. Тревожное расследование

Тревога является объективным фактом. Даже ложные тревоги указывают на то, что есть некоторые неожиданные случаи. Мы не можем исчерпать все проблемы, но мы можем установить стандартные процедуры и руководства по СОП, чтобы разбить детализированность проблем и упростить трудности. Легче локализовать проблему.

1.1 Процесс

  • не паникуйте, те, у кого гром в груди и лицо как плоское озеро, могут поклоняться генералу! Сделайте глубокий вдох и не паникуйте Чем больше вы будете паниковать перед лицом напряжения и давления, тем больше ошибок вы совершите и проигнорируете правильные подсказки.
  • Затем синхронизируйтесь в группе и вы начали вмешиваться, чтобы все могли спокойно повернуться к вам спиной.
  • 80% инцидентов — это изменения, которые вступают в силу в тот же день.
  • Для несчастных случаев стоп-лосс является первоочередной задачей.Даже если сцена разрушена, мы всегда можем положиться на подсказки, чтобы потом найти подсказки. Перезапустите, если вы не можете перейти на более раннюю версию, и откатитесь, если перезагрузка не работает.
  • Установите различные SOP от использования ресурсов до задержки. При столкновении с проблемой нам нужно только проследить за картинкой и попросить ее, что достаточно для решения 90% проблем. Тем, кто не может ее решить, нужно звонить товарищам по команде и начальству для поддержки.Голос — самая эффективная коммуникация.

1.2 Создание руководства по СОП

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

  • СОП по устранению неполадок, связанных с исключением вызовов службы поддержки
  • СОП по устранению задержек реагирования
  • СОП по поиску и устранению неисправностей автоматических выключателей
  • Mysql отвечает на СОП по расследованию увеличения RT
  • Redis реагирует на увеличение RT и исследует SOP
  • ES реагирует на RT, частота ошибок увеличивает SOP
  • Горутина ненормально поднимает СОП по устранению неполадок
  • СОП по устранению исключений ЦП и памяти экземпляра
  • СОП проверки увеличения трафика из месяца в месяц
  • Часто задаваемые вопросы о бизнесе

Ограничено внутренней чувствительностью, вот сводка, основанная на приведенных выше данных, руководство по обращению должно делать следующее:

  • Покрытие ссылок различных инструментов, владельца сервиса, лица, отвечающего за инфраструктуру, для выполненияне ищи, не спрашивай.
  • Grafana и другие инструменты хорошо справляются с Dashboard.Хорошая Dashboard может интуитивно определить проблемный API, и вы можете увидеть задержку P99, 95, 90 и т. д., QPS, трафик и прочий мониторинг. Частота ошибок является ключевым значением мониторинга,Задержки — это всего лишь видимость, ошибки могут приблизить нас к истине..

  • Проверить, жив ли соответствующий сервис? Есть ли узкие места в ресурсах (процессор заполнен и т. д.)? Горутины набирают популярность? Весь ствол взорвался?

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

  • Задержка инфраструктуры (Redis, Mysql и т. д.), проверка текущего количества подключений, количества медленных запросов, аппаратных ресурсов и т. д. вершина производительностиUSE(использование, насыщение, ошибки) — хорошая отправная точка для всех ресурсов, посмотрите на их использование, насыщение и ошибки.
  • Некоторые интерфейсы работают медленно, напрямую ограничивают ток для предотвращения лавин, захватывают запрос и смотрят на трассировку, чтобы увидеть, сколько времени занимает ссылка.

Квалифицированное руководство по эксплуатации, переданное новичку, также может определить проблемную точку и решить часть проблемы.

2. Проверка производительности

ОШИБКИ в бизнес-логике, наконец, могут быть обнаружены в корневом случае с помощью журналов и мониторинга. Но неуловимая проблема с производительностью делает нас лысыми.Здесь мы сосредоточимся на том, как мы устраняем проблемы с производительностью:

2.1 Набор инструментов

2.1.1 pprof

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

В течение временного окна CPU Profiler зарегистрирует хук для временного выполнения с программой (существуют различные средства, такие как сигнал SIGPROF), в этом хуке мы каждый раз будем получать трассировку стека бизнес-потока в данный момент. .
Затем частота выполнения хука регулируется до определенного значения, которое составляет 100 Гц (настраивается) в Golang, то есть образец стека вызовов бизнес-кода собирается каждые 100 инструкций ЦП. Когда временное окно заканчивается, мы объединяем все собранные выборки и, наконец, получаем количество раз, когда каждая функция собирается, по сравнению с общим количеством выборок, мы также получаем значение каждой функции.Относительная доля.

Поиск и устранение утечек памяти: анализ принципа профилирования кучи


Вот краткое введение:

  • pprof поддерживает два режима, между ними нет никакой разницы, второй может быть Профилированием в любое время, что более практично.
  • runtime/pprof Для фоновых служб, встроенных в службу, выборка будет автоматически завершена после завершения программы.
  • net/http/pprof предоставляет интерфейс HTTP-обработчика для создания профилирования.
  • Поддерживает профилирование ЦП и памяти.
  • Benchmark также может поддерживать профилирование go test -bench . -cpuprofile=cpu.prof

Вот результат профиля ЦП (пример изЧего вы не знаете о pprof в Go). На что мы смотрим с таким количеством данных?

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

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

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

pprof может анализировать проблемы с производительностью большинства программ.

2.1.2 trace

Если в среде выполнения возникает узкое место, например задержка планирования горутин, GC STW слишком велик, вы можете использовать трассировку, чтобы помочь нам просмотреть сведения о среде выполнения. curl host/debug/pprof/trace?seconds=10 > trace.out Здесь мы генерируем данные в течение 10 секунд, а затем трассируем trace.out через go tool.Если объем данных большой, нам нужно подождать некоторое время, и затем откройте браузер Данные в новой вкладке очень полезны.

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

Например, в примере с момента получения данных до запуска горутины прошло 4,368 миллисекунды, а данные поступили из доли pingcap.

2.1.3 Визуализация горутины

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

2.1.4 perf

Иногда pprof может дать сбой, например зависание приложения. Например, планирование заполнено (упреждающее планирование решает эту проблему). Например, самые трудоемкие символы мы можем увидеть через perf top (таблица символов встраивается при компиляции Go, ручная инъекция не требуется).

2.1.5 Швейцарский армейский нож

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

2.2 Как оптимизировать

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

2.2.1 Прикладной уровень

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

  • Объединение ресурсов, введение sync.pool
  • Сближение замков для контроля сферы использования
  • Замена библиотеки JSON и т. Д., Распределение памяти всегда снижает производительность.

Fasthttp best practicesОчень стоит нашего исследования.Производительность не является одномоментным улучшением, необходимо подобрать детали во всех аспектах.

2.2.2 Системный уровень

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

Нет универсального решения для оптимизации системного уровня, есть только компромисс Отключение Swap и NUAM часто зависит от сцены. Для получения подробной информации см.redhat tuning guide.

3. Эволюция

3.1 Continuous Profiling

Когда мы сталкиваемся с проблемами производительности, а затем выполняем профилирование, это уловка. Но во многих случаях мы не можем сохранить место происшествия или причина и явление находятся в двух измерениях во времени, что представляет для нас большую проблему. Крупнейшие компании отрасли придумали непрерывное профилирование. То же, что CI/CD. Продолжая делать выборки, Google снова и снова выходит на первый планresearch.Google/pubs/universal365…

Периодически делайте pprof через cron, архивируйте данные, а потом выбирайте анализ в любой момент через веб-интерфейс, и даже делайте diff для ppof в разные периоды времени, чтобы найти потенциальные проблемы.ConprofЭто очень полезная альтернатива с открытым исходным кодом.

3.2 eBPF + GO

eBPF — популярная в последнее время технология динамической отладки, не требующая вмешательства и скрытых точек для отладки. Созданный из bpf, да, это хорошо известный bpf (Berkeley Packet Filter), tcpdump, wireshark, все они основаны на этом, изначально инструменте захвата сетевых пакетов. Расширения могут захватывать пакеты ядра. Ядро может отслеживать систему, выставляя зонды. С помощью eBPF мы можем увидеть, что происходит на системном уровне при сбое pprof.

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

package main

import "fmt"

func main() {
        fmt.Println("Hello, BPF!")
}



# funclatency 'go:fmt.Println'
Tracing 1 functions for "go:fmt.Println"... Hit Ctrl-C to end.
^C

Function = fmt.Println [3041]
     nsecs               : count     distribution
         0 -> 1          : 0        |                                        |
         2 -> 3          : 0        |                                        |
         4 -> 7          : 0        |                                        |
         8 -> 15         : 0        |                                        |
        16 -> 31         : 0        |                                        |
        32 -> 63         : 0        |                                        |
        64 -> 127        : 0        |                                        |
       128 -> 255        : 0        |                                        |
       256 -> 511        : 0        |                                        |
       512 -> 1023       : 0        |                                        |
      1024 -> 2047       : 0        |                                        |
      2048 -> 4095       : 0        |                                        |
      4096 -> 8191       : 0        |                                        |
      8192 -> 16383      : 27       |****************************************|
     16384 -> 32767      : 3        |****                                    |
Detaching...


示例来自 https://www.brendangregg.com/blog/2017-01-31/golang-bcc-bpf-function-tracing.html

4. Резюме

Мы столкнемся с множеством странных проблем, и у нас будут разные задачи. Поскольку возникновение проблем невозможно контролировать, можно использовать такие инструменты, как Golangci-lint и CodeReview, чтобы избежать потенциальных проблем и снизить частоту и масштаб аварий. большинство вопросовЛибо проблема слишком проста, чтобы думать о ней, либо слишком сложна, чтобы ее найти.Сохранение кода в чистоте и соблюдение принципа KISS — это невиданная доселе точка зрения.

Решение проблемы — это не только конец, это начало всего. За каждой серьезной аварией должно стоять 29 мелких происшествий, 300 промахов и 1000 скрытых опасностей. Проведение хорошей работы по пересмотру и улучшению предметов — это самая большая ценность, которую дает нам несчастный случай.

Наконец, если вы очень заинтересованы в оптимизации производительности, вам не следует пропускать эту книгу.Вершина производительности.

Цитировать

Категории