Как VK проектирует код для многоядерных систем? Вроде все ресурсы CPU в твоём распоряжении, но код все равно работает медленно.
На Highload++ мы поговорили с Никитой Галушко, старшим инженером в VK — о том, как правильно работать с многопоточностью и многоядерными системами и почему чаще всего хваленный Go мешает, а не помогает, если у тебя сотни тысяч соединений и 56 ядер.
- как выжать максимум из процессора?
- как распределять потоки по ядрам?
- как перехитрить ограничения в Go?
- можно ли управлять ядрами напрямую?
Таймкоды видео
00:00:00 Введение
- Обсуждение работы на многоядерных системах с 28–56 ядрами.
- Возможность использования всех ядер из коробки в Go.
- Проблемы оптимизации процессов в Go.
00:00:42 Представление гостя
- Представление Никиты Галушки, старшего инженера ВКонтакте.
- Тема доклада: разработка систем с большим количеством ядер.
00:01:25 Проблемы многоядерных систем
- Проблемы с кэшем и согласованностью данных между ядрами.
- Необходимость оптимизации для максимальной производительности.
00:01:43 Многопоточность в Go
- Простота работы с асинхронными задачами в Go.
- Внутренний шедулер в Go автоматически распределяет задачи по ядрам.
- Ограничения Go при работе с некоторыми задачами.
00:03:44 Различия между AMD и Intel
- Важность кэша и архитектуры процессора.
- Сложности эффективной работы с AMD процессорами.
00:04:51 Проблемы кэша и протоколов
- Важность частого использования кэша для оптимизации производительности.
- Протокол Messy обеспечивает согласованность кэша между ядрами, но замедляет выполнение кода.
00:06:55 Управление кэшем в Go
- Возможность управления кэшем через структуры данных.
- Необходимость понимания работы компьютера и операционной системы.
00:09:35 Проблемы мьютексов
- Эффективное использование памяти и кэша в приложениях.
- Проблемы с использованием read-write мьютексов при высокой нагрузке.
00:12:43 Алгоритмы для решения проблем
- Алгоритмы, такие как Bravo, для улучшения коммуникации между ядрами.
- Проблемы синхронизации данных между NUMA-нодами.
00:13:58 Технические аспекты
- Синхронизация данных между NUMA-нодами через бриджву.
- Медленная коммуникация между NUMA-нодами по сравнению с одной NUMA-нодой.
00:14:36 Введение в тему
- Первый шаг: понимание основ работы процессора, памяти и операционной системы.
- Второй шаг: поиск современных исследований по проблеме.
- Третий шаг: применение найденных решений на практике.
00:15:30 Поиск исследований
- Исследования проводятся специалистами, которые получают за это деньги.
- Задача разработчика — анализировать исследования и применять их на практике.
- Не все исследования применимы на практике.
00:16:37 Рекомендации по ресурсам
- Использование Google Scholar и Twitter для поиска исследований.
- Возможность обращения в экспертные сообщества.
- Пример телеграм-канала для обмена находками.
00:18:27 Анализ производительности
- Утилита perfstat для анализа производительности в Linux.
- Измерение попаданий в кэш и количества инструкций на цикл.
- Влияние других приложений на производительность.
00:20:33 Оптимизация кода
- Различия в компиляции функций для разных архитектур ARM и x86.
- Проблемы с оптимизацией на ARM до версии 8.1.
- Возможность принудительной компиляции для определённой версии ARM.
00:23:01 Ограничения Go
- Go занимает нишу между скриптовыми и компилируемыми языками.
- Ограничения Go в управлении ресурсами и рантаймом.
- Необходимость использования хаков для оптимизации производительности.
00:25:40 Сравнение с другими языками
- Другие языки, такие как C, предоставляют больше возможностей для управления ресурсами.
- В Go сложно достичь максимальной производительности без компромиссов.
- Трудности чтения кода на Go из-за проверок безопасности.
00:28:30 Зависимость от ОС
- Приложения исполняются на Linux x86-64.
- Дистрибутив может влиять на производительность, но это не всегда критично.
- Отсутствие исследований по сравнению различных дистрибутивов Linux.
00:29:52 Советы для начинающих
- Понимание работы операционной системы: пейдж-кэш, сброс страниц на диск.
- Знание взаимодействия операционной системы с железом.
- Изучение работы железа для оптимизации.
00:30:51 Важность чтения и написания кода
- Чтение исходников драйверов и ядра помогает понять сложные аспекты.
- Написание кода способствует лучшему пониманию процессов.
00:31:36 Сбор метрик
- Метрики собираются на этапе разработки для анализа использования диска и попадания в кэш.
- Написание бенчмарков помогает оценить эффективность алгоритмов.
- Итеративная оптимизация через бенчмарки.
00:33:03 Использование StatHouse
- StatHouse эффективнее Prometheus для сбора метрик.
- Сбор верхних уровневых метрик: время записи на диск, время ответа на запрос.
- Анализ выбросов по перцисилям для выявления проблем.
00:34:56 Блиц-опрос
- Предпочтение AMD из-за опыта работы с Intel.
- Для рабочего использования предпочтительнее Mac из-за ARM-процессоров и хорошей батареи.
00:35:48 Заключение
- Подкаст завершён, упоминание о конференции Highload Plus 2024 в Сколково.
- Приглашение обращаться в компанию «Котеллов» для разработки корпоративного ПО.
Таймкоды в нейросети https://300.ya.ru/v_uWlJTV59/
В этом видео
Никита Галушко, старший инженер VK
0:00
Вот ты лично работаешь на хост машинах где 28 и даже 56 ядер Казалось бы
0:05
столько ресурсов у тебя горутины запускается на разных трудах и ты из
0:11
коробки получаешь сразу возможность использовать все ядра которые у тебя
0:16
есть в операционной системе Арм призвали чтобы оптимизировать процесс а не усложнить его ты можешь написать свою
0:23
подрезаю на помре зачем тогда нужен го а это вот Хороший вопрос кстати но го
0:29
этого не позволяет тебе это нужно делать только на си геморрой Да я поймал себя
0:34
на мысли что в какой-то момент Ты уже пишешь не Наго калов подкаст на highload
0:41
2024 всем привет дорогие друзья Добро пожаловать на катилов подкаст этот выпуск мы пишем здесь на High п+ 2024 в
0:48
Сколково где собрались самые крутые разработчики и одним из таких разработчиков — Это Никита Галушка
0:55
старший инженер Во ВКонтакте внимание в самый крупнейший социальный сети России
1:00
у каждого зрителя который тут смотрит нас по-любому есть профиль Во ВКонтакте
1:06
он здесь на конференции выступил с интересным докладом про разработку
1:11
систем Когда у вас очень очень много ядер там 28 56 ядер оказывается Когда вы
1:19
разрабатываете системы С таким количеством ресурсов вы сталкиваетесь с не очевидными проблемами Всё правильно да всё так вы
1:27
сталкиваетесь с проблемами что
1:32
те вещи которые были придуманы в CPU для того чтобы кэш на фот ядрах был валидный
1:40
везде уже играет вам в минус а не в плюс так вот он нам расскажет все секреты
Почему высокопроизводительные системы написаны на Go?
1:46
высокой производительности в многоядерных системах и о том как это применяется ВКонтакте ну что ж поехали и
1:53
первый знаешь вопрос Я честно скажу что я не Эксперт в го поэтому хотел бы задать тебе вопрос как эксперту в го
1:59
многопоточность она в го из коробки или нужны какие-то костыли го вообще
2:05
выстрелил за счёт того что там а достаточно Простая Работа с
2:12
асинхронными задачами А те подходы которые были до него они
2:18
были Ну не очень скажем А что с ними не так тот же not JS если взять там же в
2:24
принципе всё построено на а синхронности но JS построен на в Авен лупе Угу а го
2:30
построен на го рутина это совсем Разный подход у тебя горутины запускаются на
2:37
разных трудах Да и ты из коробки получаешь сразу возможность использовать
2:45
все ядра которые у тебя есть в операционной системе а распределение по за за распределение по трендам то кто
2:51
отвечает там внутренний оркестр какой-то есть а в го есть внутренний шедулер Угу
2:57
которым ты не управляешь То есть он самни он сам принимает решение На каком ядре что вот запустить
3:05
это и плюс и минус а плюс для в целом для вот разработчиков А что ты не
3:12
задумываешься ну ты просто запустил и всё А минус — это то что когда тебе надо
3:18
залезть там куда-то в кишочки Угу Это не очень удобно сделано то есть го супер
3:25
хорош в 90 там 9% за задач где его используют
3:30
но есть небольшой скоп Это вот как раз таки про то о чём был мой доклад что
3:39
есть небольшой скоп задач где Ну ты уже начинаешь бороться с или с
Какой нужен процессор для многоядерной архитектуры?
3:48
процессором и с процессором и с А вот да такой вопрос Есть ли разница
3:53
между кот для Тото
4:00
таво важен его кэш и важна его
4:10
архитектура потому что мы например исполняем на x86
4:16
64 и там всё понятно там очень много уже
4:22
исследовано на арми ВС сильно сильно сложнее те кто тся както
4:30
запуститься на армия и делать это эффективно то есть важно не просто запуститься а делать это эффективно
4:37
а они встречают некоторые проблемы в го очевидно Вот давайте погрузимся в кейс
4:45
Никиты очевидно что с этой проблемой вы столкнулись не сразу а с ростом какой-то нагрузки или Расскажи чуть подробнее что
4:52
за проблема Я знае что у вас вот ты лично работаешь на хост машинах где 28 и
4:57
даже 56 ядер Да когда у тебя десятки тысяч коннекто и сотни
5:06
тысяч по то ты встречаешься с проблемами которые
5:14
на самом деле вот большинства скрыты например
5:19
в CPU есть кэш там есть вот разные
5:25
l32 есть Коле есть он работает с памятью
5:31
и тебе важно попадать максимально часто в кэш чтобы не ходить в память потому что ходить в память этого дорого
5:38
относительно того сколько читать из кэша То есть например из L1 — это там пару
5:44
тактов сходить в память Это несколько сот тактов CPU ты не хочешь тратить это
5:50
время ты хочешь чтобы твой чтобы CPU исполнял твой код А я
5:57
сейчас объясню что я имею в виду а на CPU есть разные протоколы А например
6:04
есть такой протокол как Месси Значит его Суть в том что он обеспечивает
6:09
согласованность Шей между ядрами Но у тебя есть какая-то какие-то данные в
6:15
памяти у тебя одно ядро считало память Вот это значение к себе другое ядро Что
6:22
делать если первое ядро эти данные изменило как второе узнает что эти
6:29
данные уже для этого есть протокол Месси и он
6:34
отлично работает он как бы решает эту проблему Но если у тебя много ядер и ты
6:40
хочешь выжить из из них максимум то тебе надо думать о том как его вот обойти
6:47
потому что в момент когда исполняется этот протокол твой код не
6:54
исполняется Ну вот ты знаешь у меня вот такой прямой вопрос к тебе разве можно с
7:00
уровн Go управлять кэшем L2 L3 L1 потому что мне казалось что и за управление
7:05
кэшем отвечает как раз таки внутренний Ну сам процессор ты можешь ты можешь
7:11
повлиять на это ты можешь А ты можешь писать свои структуры данных
7:17
так чтобы они укладывались в кэш линии
7:22
так чтобы они они занимали калию полностью и
7:29
конкурировать Поэтому да можно при этом Ну то есть для
7:36
этого не надо знать там сильно го для этого надо понимать как вот устроен
7:43
компьютер как он работает как у нас работает память как работает CPU Как работает операционная система То есть
7:50
это базовый фундамент который надо знать чтобы писать действительно
7:56
высокопроизводительные системы потому что язык технологию которую ты используешь
8:02
она вторична Ну то есть если я сейчас перейду с Go на на си например
Как писать структуры данных для управления высокопроизводительными системами?
8:07
А те подходы которые я вот рассказывал в докладе они не они не изменятся Я понял
8:14
что напрямую инструкции в процессор Из Go написать не получится чтобы там управлять этим кэшем нужно правильно
8:20
организовать структуру хранения данных чтобы кэш был максимально эффективно утилизированы Ну у в ко есть ассемблер
8:26
на самом деле то есть ты можешь какие-то делать ставки на вот ассемблере но если мы говорим про кэш на CPU то Да тут
8:32
Важно как ты свои структуру данные пишешь кстати ребят если вам интересно более подробно о том как грамотно
8:37
организовать работу с данными чтобы всё это в кэше процессора укладывалось
8:42
максимально аккуратно Я то о чём говорит Никита ссылочка внизу будет на Его доклад Посмотрите более
8:49
подробно Привет я Валерий колов мы разрабатываем корпоративное программное обеспечение веб-сервисы и мобильное
8:56
приложения и конечно же нам НВИ [музыка]
9:05
дизайн тево Мы работаем со сложными задачами Лично я люблю высоконагруженные
9:10
продукты с упором на безопасность данных и последующую работу с ними если вам нужно рассчитать стоимость разработки
9:16
присылайте нам запрос сделаем вам расчёт дизайн концепцию и защитим ваш проект
9:21
перед стейкхолдерами в любом случае подпишитесь на наш Telegram канал Заходите на сайт cat.com и оставайтесь с
9:28
намив подкаст мы с тобой поговорили о самой верхнем уровень механики давай чуть-чуть опустимся поближе к народу так
Какие проблемы возникают в мьютексах?
9:34
сказать мне кажется проблема возникает ещё в самих юкса А да если мы говорим про то что у нас
9:42
есть какая-то жирная тачка а то скорее всего там есть и много
9:48
памяти если у тебя есть много ФТ памяти у тебя стоит вопрос как её эффективно
9:55
использовать а эффективно её утилизировать и здесь уже стоит вопрос как построить
10:03
кэш в ней уже да то есть не кэш там в CPU Да а кэш именно кэш
10:09
приложение Ну то есть самое пример чтобы понимали наши зрители
10:16
это да Но при этом мы не хотим платить за походы по сети мы хотим чтобы кэш был
10:26
внутри нашего приложения Обычно вот решается через Map Просто берут Map берут read MX Почему
10:35
read MX потому что кэш обычно конечно читается но всё же вот иногда меняется
10:41
поэтому мы берём Лок на чтение отдельный есть он быстрый в кавычках вот а и есть
10:50
отдельный Лок на запись и вот они а под отделяются И поэтому ты можешь
10:57
эффективно написать кэш но эффективно опять же для большинства приложений так
11:04
Но в нашем случае когда а повторюсь сотни
11:09
тысяч запросов в секунду идёт Да тебе уже этот подход Не совсем подходит А в
11:17
что мы убираемся в системное ограничение по мьютекс или в железное физическое ограничение в данном случае мы упираясь
11:29
CPU как вот работает его кэш А когда у
11:35
тебя к Ну я про го говорю Да он сделан на а
11:41
Томика внутри которые меняются на каждое чтение это приводит к инвалидация кэша и
11:49
опять же запускается протокол Мисси про который я говорил 5 минут вот до
11:57
этого и в это момен наш код не исполняется и исполняется какой-то
12:02
другой код мы не хотим этого мы хотим чтобы CPU эффективно
12:10
утилизированные подходы чтобы заменить который вли есть и его все
12:18
используют и опять я повторюсь для большинства по задаче это так то есть если
12:25
вы не понимаете для чего такие вот алгоритмы как Браво про которые я
12:31
рассказывал в докладе да то лучше не вот использовать их потому что А ну вы
12:40
скорее всего даже не увидите какой-то Профит а суть алгоритмов которые
12:47
пытаются лучше подойти к решению проблемы Ну и в целом кса это то что
12:55
А у тебя на сервере есть не просто там
13:00
28 ядер или 56 ядер у тебя а
13:07
на на сервере есть несколько нума НОД одна нума нода это один процессор
13:13
насколько я знаю да и обычно их две если двух процесор СБО да и у тебя получается
13:19
в одном 28 и в другом 2 я не автономный насколько я помню друг от дружка живут да и у тебя и у тебя стоит вопрос Как
13:27
эффективно произвести коммуникацию так чтобы они не конкурировать
13:32
[музыка] этот вопрос сейчас немножко технический
13:38
вопрос Если ты на него ответишь ничего страшного но не для того ли придуман там
13:44
Channel если это говорить про обычные десктоп я даже не помню сколько каналов есть одновременно у серверной материнки
13:51
для того чтобы про могли обращаться как бы автономно друг от Друж
13:59
тебя условно У тебя есть какая-то вот Память у тебя нума нода там первая её
14:06
прочитала и так как у тебя много потоков много ядер ты хочешь и всех
14:12
утилизировать ты используешь и и вторую тоже она тоже её читает и у тебя
14:17
возникает вопрос как эти данные синхронизировать когда у тебя одна нума
14:23
нода там всё быстро потому что у тебя на вот одном кристалле А когда две ты
14:28
общаешься через б вот этот вот между ними а ты не хочешь этого делать потому что это медленно Ну медленно
14:34
относительно конечно Ну вот обычного каша и как
14:39
быть слушать мой доклад Ну давай давай Подожди это классный утверждение Ну
14:45
давай мы в подкасте чуть-чуть дадим подробности нашим ребятам значит Ну
14:51
самый первый так сказать шаг Да это в
14:57
целом понимать базу того как устроена CPU Как устроен
15:04
процессор Как устроена память Как устроена операционная система второй
15:10
этап — это искать перы
15:15
современная где исследуется эта проблема потому что
15:22
наверное недостаточно времени в сутках
15:27
чтобы ты сам это мог делать есть умные люди которые за это получают деньги
15:34
которые на это тратят своё время они исследуют эту проблему и
15:41
а выводят разные гипотезы о том как А можно подойти к Вот её решению А твоя
15:49
задача из этих пеперо как-то выть что-то интересное и пробовать их на практике потому что на
15:56
самом деле не всё что на самом деле побо и на практике примени
16:05
Так мы с тобой обсудили объяснил про Пепе Ну про Пепе как-то знаешь так вот сидите читайте А
16:12
можешь дать конкретне что почитать может быть у тебя есть какая-то готовая информация
16:18
почитать на что ориентироваться вот я реально столк с этим кейсом потенциально что
16:24
м за сэкономить людям время А мы можем
16:31
оставить ссылочку собственно алгоритм ва чтобы люди сразу могли его почитать в
16:37
описании Господа в описании Да если вы пишете на го то мы оставим ссылочку её и
16:43
на реализацию Наго да на самом деле тут нет вот ответа на вот вопрос Ты
16:53
переломаю Ну откуда где ты сам гуглишь идёшь на есть Google СР
17:02
это поисковик по
17:18
перампл это А я думаю мы тоже оставим ссылочку на него конечно ссылочка в
17:23
описани вот а ты по крупицам собираешь в разных местах может быть есть какое-то
17:29
сообщество Куда можно обратиться Вот именно с такой нестандартной проблемой экспертное сообщество Я знаю что вот у
17:35
тебя есть например свой Telegram канал он называется кстати ребята смотри что
17:41
нашёл Да я пытаюсь там именно вот делиться такими вот жемчужинами да
17:47
которые я вот нахожу поэтому он и так называется смотри что нашёл на сам без
17:53
без шуток без шуток если вы сталкиваетесь с такими уникальными проблемами
17:59
то кроме как рча и
Как правильно искать ответы на сложные вопросы в разработке?
18:06
прочитывает вот решения Ну можно ещё ходить на конференции Как как вариант А
18:12
давай гипнотизируют по твоему кейсу я так понимаю ты нашёл готовую информацию или сам что-то
18:18
ресл я сначала нашёл пепер Да который вот реализовывает
18:26
этом его сам и потом нашл вот реализацию на гитхабе А если наш потенциальный
18:33
коллега смотрящий столкнётся с проблемой где нет какой-то подсказки или готового Пепе
18:40
с точки зрения ресерч С чего ему начать как ему Трейси Вот вот эти все проблемы
18:46
То что пушку в свой локальный кэш L2 и1 и3 неправильно укладывает данные или то
18:52
что у нас ну узлы некорректно обращаются к ним вот как это треть понимаешь иногда
18:58
же Надо же понять проблему есть такая прекрасная утилита для Linux стат Угу
19:06
а на самом деле на процессоре есть много счётчиков Точнее не так а счётчиков там
19:13
ограниченны вот количество но а именно выбор вот из которых их считать
19:22
он достаточно большой то есть с помощью можно посчитать очень много можно
19:27
посчитать сколько было Да не в кш именно в процентном соотношении когда у тебя работала программа Угу можно посчитать
19:33
сколько у тебя инструкций на цикл было вот по поводу попадание в кэш ведь с кэшем работает не только наш
19:38
изолированный апликейшн Там же ещё и операционная система есть есть какие-то
19:43
другие рядом стоящие приложения как вот это вопрос уже как это
19:49
тестировать Да ну как это счётчик-то будет некорректную информацию показывать Почему нет у тебя стат привязан к твоему
19:58
апликейшн да А конечно если есть какое-то рядом
20:03
приложение которое активно работает CPU оно 100% будет влиять потому что оно
20:08
будет вымывать кэш Да от этого не деться берите в тачку
20:15
где Ну никто кроме вас не исполняется Ну как бы ну а как ещё подойти к этому
20:21
вопросу Окей То есть перста — это Аль матор Как говорится для нашей задачи стат — это ну вот с того с чего можно
20:31
начать да А если мы говорим про
20:37
А ещё как бы можно посмотреть Во что компилируется а разные функции потому
20:45
что например на армии У нас есть атоми да для x86 64 — это физически одна вот
20:55
инструкция для CPU для для Арма А это не всегда так для Арма
21:05
А у тебя если версия Арма ниже
21:10
8,1 то Каз превращается в цикл Да ну что за
21:17
бред а Арм призвали чтобы оптимизировать процесс а не усложнить его
21:22
а у тебя Каз превращается в цикл внутри и а
21:29
если ты компилирует то надо прям очень смотреть
21:35
Во что это выходит с 81 это не так это уже одна
21:41
инструкция но например ваш процессор может не поддерживать эти инструкции и
21:47
тогда это Цикл А это нуль Честно говоря я уже не видел а
Зачем вообще тогда нужен Go, если фатализация на ассемблере?
21:53
процессоры ниже там восьмой версии супер древние Android телефоны
21:59
это так это так но но в го например Аа в 123 по-моему это пофиксили или в 1
22:09
24 по фиксе А там есть проверка что на какой версии
22:16
мы исполняем и эта проверка происходит в ран тайме Каждый раз когда ты вызываешь атоми реально но это же оверхед ресурсы
22:24
А нельзя как-то принудительно ну скомпилировать исключительно под
22:30
определённую версию теперь можно теперь можно вот начиная с 13 можно но если вы
22:37
живёте на там 122 например потому что вы не готовы ещё приходить на вот 1223 там
22:43
у вас какие-то крупные а крупные участки кода Я не знаю И ещё
22:49
каким-то причинам неважно то это так ты ты можешь написать как бы свою лизации
22:57
на помре тогда будет всё хорошо Зачем тогда нужен го м нам а это
23:04
вот Хороший вопрос кстати потому что а го в
23:09
начале своей Ну своего взлёта занял
23:15
нишу такую между скриптовые под языками и компи компилируемые да типа c+ и люди
23:25
переходили с питона там с ПХП на го а и казалось что вот она серебряная пуля это
23:35
компилируемый язык сгц решает проблему асинхронно
23:42
есть вот работа с пакетами всё всё всё круто типа но оказывается что есть ниши
23:53
где вот э закрытость го то что у нас есть ранта и мы на него никак не можем
24:00
влиять и на него никак не можем Ну как-то с ним взаимодействовать то есть
24:06
условно мы не знаем На каком CPU мы исполняем как минимум
24:11
А я имею в виду на каком номере вот ядра это уже начинает быть проблемой Но мы же
24:18
можем при запуске любого процесса в том же линуксе во-первых я не помню точно но
Что будет, если указать, на каком конкретном ядре запускать процесс?
24:24
указать На каком конкретно ядре физическом запустить процесс и лимитировать количество ядер доступных
24:30
ему это не решает проблема которую ты описываешь Нет не решает потому что
24:36
например в докладе Я делился хаком и только с ним вот работают там некоторые
24:43
вот алгоритмы которые я описал условно У тебя есть приложение которое использует
24:49
много ядер И ты хочешь чтобы у тебя какие-то данные были привязаны только к
24:55
одному подру а какие-то данные другому игру без хаков в го этого не сделать
25:03
Хаки или костыли Хаки называешь Хаки хорошо Хаки потому
25:11
что ну сейчас меня за хейтят все те кто вот любит го на самом деле я тоже го
25:19
люблю я на нём пишу уже лет 10 но главная под проблема сейчас на мой
25:26
взгляд именно взгляд с [музыка] з написания высокопроизводительного кода
C, Rust, Zig — свободные языки, а Go ограничивает разработчика?
25:34
это то что есть монополизация ран
25:39
тайма Сейчас секунду я задумался А В како какой язык позволяет нам управлять
25:45
этими самыми ресурсами чтобы мы сами из кода могли определять На каком ядре
25:50
работать ну помимо Си Ну СТ
25:56
зик То есть все это То есть все вот языки которые предоставляют тебе свободу
26:02
го не предоставляет тебе свободу в этом плане Ну может Его высокая скорость как
26:07
раз-таки и обусловлена то что там шедулер идеально написан Если вы знаете как как как вот написан дуле в Go но он
26:16
Ну конечно он не вот идеально написан потому что он пытается решить общую
26:22
задачу что типа А давайте чтобы в целом как бы все плюс-минус вот работа ли по
26:29
эффективно но например если ты активно вот работаешь сетью
26:34
то закрепить поток на конкретном ядре который будет
26:41
а именно подн тлум таким Да это будет
26:46
супер вот оптимально но го этого не позволяет тебе это нужно делать только на си
26:51
геморрой Да ну как бы если Твоя цель стоит а
26:59
максимальная производительность то ты как бы идёшь на компромиссы у меня в прошлом году
27:07
был доклад про то как из выжимать максимум
27:13
производительности и я поймал себя на мысли что в какой-то момент Ты уже пишешь не
27:19
Наго перел наты на код
27:27
смотри уже практически То есть ты везде пытаешься сэкономить Ты везде
27:33
пытаешься сделать так чтобы А например вот вот например А в го у нас
27:41
есть проверка выхода за за границ массива потому что у нас го типа
27:47
безопасный язык но ты уверен потому что ты свои данные знаешь ты уверен что там его не будет да это риск потому что
27:54
вдруг будет тогда ты потешь память но год этого не знает и ты всякие всякими
28:01
правдами и неправдами пытаешься сказать го чтобы он эти проверки не вставлял и и
28:07
Код Этот читать очень тяжело ты без комментариев его не понимаешь то есть ты
28:12
не понимаешь почему эта сточка вообще здесь есть зачем мы трогаем какую-то память которая нам ещё не нужна А
28:19
поэтому го очень очень хороший язык он прекрасен
28:25
но иногда а
28:30
ты думаешь что вот изначально для там этой задачи надо было выбрать другой язык ноже уже поно уже поздно потому что
28:38
написано много всего вокруг вот исходя из твоей насмотренности Есть ли какая-нибудь
Есть ли зависимость от операционной системы?
28:44
зависимость от операционной системы там bsd винда Слушай у нас все наши приложение
28:53
исполнятся нае X64
28:58
ядре А так Тебе же не так важно
29:04
типа дистрибутив тебе важен просто версия ядра ну дистриб тоже какой-то
29:09
оверхед накидывает бывает не встречал хорошо то есть грубо
29:16
говоря Вы не проводили какое-то исследование на чём лучше запустить на fre bsd или на унту какой-нибудь
29:22
А я о таких тестах не знаю Ну хорошо давай вот так я отвечу Спасибо Спасибо
29:29
большое Никит ты очень много классной информации выдал Который невозможно на гуглить нигде интернете кстати вот на
29:35
два доклада про которые Никита говорил ссылочка будет в описании первый с High 2023 уже вышел и доступен к просмотру а
29:42
вот с H 2024 надеюсь что к моменту публикации этого выпуска уже тоже станет
29:48
доступен но всё равно ссылочку мы оставим поэтому периодически заходите на это видео и просматривайте ну и идём
Где искать ответы и какие метрики собирать?
29:53
немножко к финалу Можешь ли ты дать совет тем людям которые рано или поздно столкнуть той же пробле что им важно
30:00
сделать в самом начале чтобы потом было легче если мы говорим с точки зрения знаний то с начала хорошо бы знать как
30:11
устроена операционная система если работаете с диском то там есть ш в
30:18
операционной системе что если все страницы станут
30:24
грязными Сколько времени е потребуется на диск И как вы это увидите на Метрика
30:33
а потом спуститься на ещё один уровень понять как операционная система работает
30:39
с железом и далее на ещё один уровень А
30:44
собственно Как работает э железо Потому что некоторые оптимизации невозможны без
30:50
того что без понимания того а как оно работает Ну например да попадать или не
30:57
попадать в Кош линию самое базовое наверное то то что есть это как бы вот
31:03
основа с неё начать а далее а совет который я не понимал когда
31:11
начинал только это брать писать код И что самое главное читать потому что
31:20
А какие-то вещи ты можешь узнать только просматривая какие-то вот исходники там
31:27
роверов или ядра ну какие-то такие вещи которые не лежат на
31:34
поверхности Слушай я обещал тебя что отпущу но у меня есть очень важный вопрос Вот супер важный Ты часто и много
31:41
говоришь про метрики Есть ли Best практис как вот эти метрики нестандартные метрики собирать
31:47
использованием чего Явно же хочется чтобы у тебя был красивый интерфейс какая-нибудь графана чтобы ты не сидел
31:53
вот так вот глазками не высматривал в консоль и не запоминал Циферки если мы говорим про метрики там
32:01
использование диска попадание в кэш или ещ что-то их обычно собирают на этапе
32:09
разработки Ну то есть вы сделали какую-то версию своего
32:15
алгоритма что первое что надо сделать это написать Ну помимо теста написать к
32:24
нему проанализировать посмотреть а Всё ли
32:32
хорошо а можно ли лучше то есть представить
32:40
а теоретический минимум для вашего пота алгоритма и попытаться к нему
32:49
приблизиться Это только вот
32:56
итеративности бенчмарком запуска а то есть на этапе вот разработки если
33:04
мы говорим про уже эксплуатацию то Ну я не могу не э сказать что надо
33:11
использовать вместо прометеус а Хаус потому что Хаус куда эффективнее
33:19
работает а хаус — это разработка ВКонтакте Тина рекламка рекламка да Да
33:28
вот а то здесь уже надо снимать верхние уровневые метрики то
33:35
есть сколько времени у вас длится запись на диск да сколько времени Вы отвечаете
33:43
на запрос потому что ответ на запрос может зависеть от того а пишете Вы на
33:51
диск да ну то есть например пришёл запрос вы что-то записали на диск И вы ждёте пока на диск запишется важно
33:58
смотреть не среднее по времени а важно
34:03
смотреть выбросы по перн силим Ну то есть
34:10
девяносто девятый например он очень хорошо показывает е ли какие-то явные
34:17
проблемы иногда то есть проблема может возникать не постоянно она может не знаю
34:24
Там типа каждую ночь там в 2:00 ночи возникать А вы там смотрите
34:32
в своё рабочее время только например ну на график видишь Насколько полезно важно
34:39
бы оказался мой вопрос оказывается Казалось бы в простой вещи смотрите метрики столько информацию Спасибо
Блиц
34:44
большое Никит Спасибо отка на High
34:50
2024 блиц опрос Господа первый вопрос AMD или Intel AMD
34:58
Почему ты за красных потому что
35:03
Intel профукал всё что мог но ты вот Нол его
35:10
То есть тут как знаешь под обида То есть ты Ну я предпочитаю под просто потому
35:18
что за Intel Вот обидно подожди ну ты сейчас новый комбо себе собирал бы на ЧМ на вс-таки на конечно а ты не веришь в
35:25
концепцию есть такая концепция называется то что Windows идеально работает именно
35:33
с Я не слышал это подход к следующему вопросу Linux Windows или Mac Смотря для чего
35:41
для личного использования смотр для какого личного испо [музыка]
35:47
рабочего для рабочего я бы выбрал маг Почему
35:56
вообще пому Что хорошо держит батарейку хороший экран Ладно аргумент Спасибо
36:02
большое Ну что ж дорогие друзья наш большой и тяжёлый откровенно технический
36:07
подкаст Подошёл к концу напомню в гостях у нас был Никита Галушка старший инженер
36:12
Во ВКонтакте если вам нужно разработать корпоративное программное обеспечение Где требуются специалисты с уникальной
36:19
экспертизой обязательно Обращайтесь к нам в компанию котлов ссылочка на заявку в описании Ну а пишем этот выпуск здесь
36:25
на конференции High п+ 2024 в Сколково С вами был я Валерий котлов SEO компании
36:32
котлов Подписывайтесь на наш канал ставьте лайки пишите комментарии До скорых встреч пока-пока
36:39
отказ на highload 2024