1 of 67

ПРОФИЛИРОВАНИЕ И ОПТИМИЗАЦИЯ ПРИЛОЖЕНИЙ НА GO

Нещадин Иван

Senior engineer @ Antimonolith

Москва — 2021

Цвет фона

На этом слайде подразумевается цветной фон. Задайте его цвет в верхней панели Фон (пожалуйста, используйте фирменные цвета, заданные в строке Тема).

!

Заглавные буквы

Для заголовков используйте заглавные буквы.

!

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

2 of 67

2

3 of 67

3

4 of 67

4

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

5 of 67

5

6 of 67

6

7 of 67

7

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

8 of 67

8

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

9 of 67

9

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

10 of 67

10

Но несмотря на то, что процессоры теперь умеют выполнять несколько задач одновременно, проблема все еще остается. Все дело в том, что сколько бы мы распаралелливали вычисления, все равно существует некий предел. Есть такой закон, который называется закон Амдала. Он еще в далеком 1967 году сказал - суммарное время параллельного вычисления на процессорах не может быть быстрее времени вычисления самой медленной части. И это довольно логично. При этом, у нас еще имеется такая проблема - далеко не все задачи можно вычислять паралелльно. Я вспоминаю простой пример - вычисление чисел фибоначчи. По определению, каждое число фибоначии равно сумме двух предыдущих чисел. Т.е. пока мы не посчитаем предыдущие числа, мы не можем посчитать следующее, поэтому эту задачу нельзя считать параллельно. И это далеко не единственный пример, когда параллельность никак не помогает нам ускориться.

11 of 67

11

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

12 of 67

12

Я нашел такие данные и был поражен. Это табличка, которая показывает задержки по работе с различными компонентами ПК. Так вот, в левой колонке мы видимо базовую задержку для устройства, а справа - как ее видит процессор из своего мира. Представьте, что вы - процессор. Вы совершаете в 1 секунду 3.4 миллиарда действий в среднем. Сходить в кэш первого уровня - 3 действия, соответственно для вас это быстро. Сходить в кэш второго уровня уже 9 действий, ну тоже неплохо вроде. В Кэш третьего уровня - 43 действия. А я напомню, что кэш третьего уровня - это кэш, который шэрится между ядрами. Так вот, если бы вы были процессором, то сходить за данными в кэш третьего уровня - 43 секунды для вас. А чтобы сходить в оперативную память за данным - 6 МИНУТ. Представляете? Это как сходить до магазина. А считать данные с SSD в некоторых случаях как проехать на поезде участок Москва-Краснодар или проехаться по транссибу. Т.е. данные на диски далеки от процессора также, как далек от нас сейчас Владивосток (ну это если вы находитесь в Москве, конечно).

Поэтому, еще одним способом ускорить производительность в нашем мире - сократить эти задержки

13 of 67

13

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

14 of 67

14

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

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

15 of 67

15

16 of 67

16

Я был наслышан о законе Мура и о том, что необходимо оптимизировать свои программы, но также были требования бизнеса, что необходимо делать новые функции, а не оптимизациями заниматься. Оптимизации не приносят денег, в то время как новые функции приносят. Ну и делались задачи, пилились фичи, оптимизациями специально никто не занимался. Но вот от бизнеса пришла задача - необходимо разработать программу, для работы с оборудованием. Оборудование это подключается при помощи USB портов к ПК и работает у клиентов, а удаленный сервер этому оборудованию должен удаленно отдавать команды. Ну и я тогда умел только в WEB стек, десктопных программ никогда не писал, и C++ прости господи, не знал. Ну и было решено пилить на том, на чем умеешь - на Electron.

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

17 of 67

17

18 of 67

18

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

19 of 67

19

20 of 67

20

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

И мы для наших сервисов можем запросить определенное количество ресурсов, такие как cpu, память, диск. Было необходимо понять, почему троттлится CPU, а значит необходимо разобраться с тем, как этот механизм работает в kubernetes.

21 of 67

21

Когда мы запрашиваем 1cpu в kubernetes, это не значит, что нашему сервису будет полностью выделено одно ядро из 48 ядер процессора, это лишь означает, что нашему сервису будет выделено время работы cpu равное времени работы одного ядра. Это означает, что если наш под не будет успевать выполнять свою работу в выделенный ему промежуток времени, остаток времени будет являться временем троттлинга. Т.к. в моем у пода размер medium, это значит что ему выделено 2cpu, и троттлинг 0.8 означает, что под подтребляет времени работы почти как 3cpu!�

И тут я задумался - и что же с этим делать? Как найти, почему мой код потребяет так много процессорного времени?

22 of 67

22

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

И я начал разбираться сначала на простых примерах.

23 of 67

23

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

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

24 of 67

24

25 of 67

25

26 of 67

26

27 of 67

27

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

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

28 of 67

28

29 of 67

29

В Go есть встроенные средства тестирования, и один из таких способов - написание бенчмарков. Бенчмарки позволяют подсчитать производительность нашего кода, а также выявить проблемы в коде, которые проявляются только под нагрузкой. Поэтому, для сбора профилей как правило используются бенчмарки. В Go, бенчмарки должны находиться в файлах, имя которых заканчивается на _test, а сами методы бенчмарков должны начинаться со слова Benchmark и в аргументах принимать один единственный аргумент - b *testing.B. Это необходимо для того, чтобы Go мог найти бенчмарки в коде.

30 of 67

30

31 of 67

31

32 of 67

32

33 of 67

33

34 of 67

34

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

И я решил разобраться, что же собственном происходит. И в этом мне как раз и помог pprof, помните, с чего мы начинали? Сбор профиля при помощи бенчмарков.

35 of 67

35

36 of 67

36

37 of 67

37

38 of 67

38

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

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

39 of 67

39

Для того, чтобы разобраться, есть еще одна полезная команда интерактивного режима - web. Если ее ввести, то в браузере Google Chrome откроется окно, в котором будет график стека вызовов в собранном сэмпле. При этом, более крупные стрелки и блоки показывают функции, которые затратили больше времени на выполнение. А также видно, сколько конкретно времени было потрачено на каждый конкретный блок и на цепочку блоков. Это удобный способ поиска проблем с производительностью.

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

40 of 67

40

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

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

Это ли не чудо? Я ввел эту замечательную команду и название своего метода, и что я увидел? Ну во-первых, надо разобраться, что я получил в выводе. Есть две колонки - flat, cum. В них записано время в миллисекундах, сколько по времени в сэмпле встречался вызов. Flat - время потраченное на сам вызов, cum - на все внутренние вызовы в том числе. И я сразу заметил, что больше всего времени было потрачено на строке append. Это подозрительно, но пока до конца непонятно, и я пошел разбираться дальше.

41 of 67

41

Я решил попробовать вызвать команду list для метода runtime.mallocgc, но это была ошибка. Шучу, на самом деле нет, просто мне выдалась большая простыня кода, и я ее даже на слайд не смог уместить. Но самое главное подтвердилось - это действительно функция для выделения памяти для объектов и она тратит больше всего времени на выполнение.

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

42 of 67

42

43 of 67

43

В целом memprofile по функциям мало чем отличается от cpuprofile, разве что он показывает несколько другое, в отличие от cpuprofile. При помощи него мы можем смотреть, какие функции выделяют память в heap и где они это делают. Я ввел команду top10, чтобы узнать топ-10 мест, где выделялась память и в списке обнаружил лишь свой метод. Чтобы узнать, где конкретно выделяется память, можно использовать команду list, аналогично cpuprofile. Можно ввести имя метода и тогда команда покажет строки кода, в которых выделялась память. Я ввел название своего метода для копирования слайса и обнаружил, что больше всего памяти выделяется в строке с вызовом метода append. Но как же так, я всего лишь делаю копию массива и потом переношу туда элементы из старого! Или это не так?

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

44 of 67

44

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

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

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

45 of 67

45

Запустил бенчмарк, смотрю результаты. 67 наносекунд на операцию, 80 байт памяти на операцию и 1 аллокация на операцию. Неплохо, вроде было 3 аллокации 100 с чем-то байт памяти или вроде того. Стало лучше кажется, теперь аллокация одна, в точности как и должно быть.. Но как-то не очень наглядно такие результаты бенчмарков, хотелось бы их как-то сравнить с предыдущими. И вы не поверите, для этого тоже есть специальная утилита. Правда есть минус - она не встроена в Go, но это нам не помешает ее установить и использовать. Утилита называется benchcmp

46 of 67

46

47 of 67

47

48 of 67

48

49 of 67

49

50 of 67

50

51 of 67

51

А вот что происходит внутри пакета pprof. В нем есть функция init, которая регистрирует хендлеры в стандартном сервере Go, необходимые для pprof. Если кто не знает, функция init выполняется при импорте пакета и именно поэтому импорта пакета достаточно. И пакет импортируется через нижнее подчеркивание, т.к. при этом как мы никаких функций из пакета не используем, а делаем это только ради функции init. Но это все хорошо, когда мы используем стандартный сервер, а что если мы хотим использовать сторонние пакеты для роутинга?

52 of 67

52

Так как у нас в Авито во всех сервисах paas, то у нас есть уже реализация регистрации методов pprof. У нас используется пакет gorilla/mux для роутинга, поэтому я показываю пример регистрации методов pprof именно в этом пакете. Метод ServePProf создает сервер на порту 3366, задает таймауты и записывает в качестве хендлера mux. Также пришлось прописать все пути заново и забиндить их на методы пакета pprof. И обратите внимание на ожидание канала из ctx.Done, мы запускаем хендлеры pprof в горутине, поэтому нам необходимо закрыть их, когда закроется основной сервер, и для этих целей идеально подойдет использование ctx с его каналом, оповещающим о закрытии контекста. Все что мне остается, это в main файле вызвать метод ServePprof и передать в него контекст сервера

53 of 67

53

54 of 67

54

55 of 67

55

56 of 67

56

57 of 67

57

58 of 67

ПРОФИЛИРОВАНИЕ И ОПТИМИЗАЦИЯ ПРИЛОЖЕНИЙ НА GO

№2 - Практика

Нещадин Иван

Middle engineer @ Antimonolith

Москва — 2021

Цвет фона

На этом слайде подразумевается цветной фон. Задайте его цвет в верхней панели Фон (пожалуйста, используйте фирменные цвета, заданные в строке Тема).

!

Заглавные буквы

Для заголовков используйте заглавные буквы.

!

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

59 of 67

59

60 of 67

60

61 of 67

61

62 of 67

62

63 of 67

63

64 of 67

64

65 of 67

65

66 of 67

66

67 of 67

67