Перевод Debunking 5 Stubborn Systems Performance Myths
Немногие вещи так живучи, как мифы. Некоторые мифы когда-то были правдой, а другие возникают словно из ниоткуда. Примером первого является миф о том, что в экстренных случаях лучше всего вводить лекарство прямо в сердце. Это было показано в сцене из «Криминального чтива», где героиня Умы Турман оживает после передозировки. Но эта практика вышла из употребления еще в 70-е годы, когда врачи узнали о более простых, безопасных и эффективных методах. Примером последнего типа мифов может служить история о том, как начинал свою карьеру покойный комик Патрис О’Нил. Легенда гласит, что он насмешил комика, а потом осмелился выйти на сцену и попробовать самому. И он попробовал. Но в документальном фильме о его жизни рассказывается гораздо более простая история генезиса, которая обескуражила многих его поклонников. Мифы о производительности систем ничем не отличаются.
Некоторые мифы о производительности систем когда-то были правдой. Другие, кажется, были выдуманы из воздуха. В этой статье описаны 5 таких популярных мифов о производительности, некоторые из которых когда-то были правдой, а некоторые - никогда. Попутно я постараюсь опровергнуть их раз и навсегда. Мы перечислим их в обратном порядке распространенности, основываясь на моем личном опыте.
Миф №5. Опыт работы с инструментами == Экспертиза в производительности систем
Успех зависит не от инструментов. Никто никогда не спрашивал Хемингуэя, каким карандашом он пользуется.
Chris Brogan
Как вы думаете, первая группа писателей, освоивших Microsoft Word, стала писать лучше, чем те, кто пользовался печатными машинками? Или первая группа журналистов, использовавших смартфоны/планшеты, стала лучше тех, кто пользовался желтыми блокнотами? Это понятие совершенно абсурдно. Писатели и журналисты становятся экспертами, совершенствуя свое ремесло, а инструменты продуктивности только улучшают их врожденные способности.
Тем не менее, на LinkedIn и Twitter инженеры описывают себя как «эксперт JMeter» или «мастер Intel VTune». Подразумевается, что мастерство владения инструментом равносильно мастерству в области производительности в целом. Ничто не может быть дальше от истины.
Systems Performance experts хорошо разбираются в фундаментальных основах. Они разбираются в Queuing Theory, Systems Architecture, CPU microarchitecture, OS/kernel/IO basics, Benchmark Design, Statistical Analysis и т.д. Инструмент, которым владеет эксперт, только усиливает его с большим трудом заработанную способность побеждать драконов производительности или раскрывать более глубокие идеи.
На самом деле, знание приблизительных значений latency для различных операций (например, системных вызовов, переключения контекста, случайных чтений и т. д.) позволяет экспертам проводить математические расчеты, чтобы определить, когда эти инструменты выдают ложные результаты. Такого чутья на ложные отчеты не выработаешь, просто изучая сами инструменты.
И наконец, когда на смену устаревшему инструменту прошлого года приходит сексуальный инструмент сегодняшнего дня, фундаментальные знания эксперта без проблем передаются, а «эксперт по инструментам» оказывается в ситуации нестабильного рынка труда.
Этот миф о производительности никогда не был правдой. Уделяйте больше времени оттачиванию знаний фундаментальных основ производительности систем, дополняя их инструментарием.
Миф №4. Достаточно отслеживать потребление памяти
Вы - владелец нового ресторана. Поэтому вы отслеживаете все аспекты повседневной работы, чтобы не пропустить ни одного случая, когда вам понадобится большее количество персонала. За последние несколько недель ресторан заполнялся только на 50%, и за столиками никогда не было очереди. Поэтому вы не видите необходимости в увеличении штата.
Но потом вы замечаете, что на Yelp появляется множество негативных отзывов: посетители ресторана жалуются на время ожидания заказа. “Что? Как такое может быть?! Мы никогда не заполнены более чем на 50%, и у нас никогда нет очереди! Как это происходит?” Поговорив с персоналом, вы узнаете, что ресторан привлекает бурно развивающихся местных гурманов. Придирчивые, они часами заказывают по несколько блюд за все время пребывания в ресторане, часто возвращая заказ из-за мелких недочетов. Другие обедающие в ресторане требуют гораздо меньше, но при этом терпят длительное ожидание из-за того, что несколько столиков гурманов перегружают кухню. Штат сотрудников, основанный исключительно на вместимости ресторана, оставляет серьезное слепое пятно в вашем планировании.
Аналогично, существует миф о том, что для мониторинга производительности достаточно отслеживать только потребление памяти. Честно говоря, инструменты мониторинга на рынке поддерживают этот миф. Большинство инструментов по умолчанию предлагают только глобальное использование оперативной памяти и использование оперативной памяти для каждого процесса. Они также отслеживают поведение свопинга для обнаружения нехватки оперативной памяти, как владелец ресторана проверяет заполненность ресторана или наличие внешней очереди. Но как насчет проверки процессов, монополизирующих Memory Controller (MC) постоянным потоком запросов? Такие процессы могут использовать только 10% доступной оперативной памяти, но нагрузка на обмен данными в пределах этих 10% может быть просто чудовищной.
Помните, что MC - это общий ресурс, как и кухня с нехваткой персонала. Если один процесс (или столик) нагружает этот общий ресурс потоком запросов R/W (или частыми требованиями заказать еду), это влияет на производительность других процессов, проходящих через тот же MC (например, других столиков в ресторане).
Как вы думаете, могут ли эти всплески на 2-3ГБ/с оказать какое-либо влияние на задержку?
Я уже знаю, о чем вы думаете. “Такое приложение выдаст себя внезапным скачком CPU%, который я уже отслеживаю”. Возможно, в прошлом такое возражение было более обоснованным. Но теперь, когда клиенты больше не терпят безумных длинных хвостовых задержек(long-tail latencies), разработчики приложений обратили на это внимание. Такие приложения, как ScyllaDB и RedPanda, используют схемы thread-per-core, при которых потоки работают на выделенных ядрах, чтобы избежать задержек при sleep/wakeup режиме и переключении контекста. Такой spinning позволяет поддерживать CPU% на этих ядрах в диапазоне 90+ даже в режиме простоя. Трейдинговые приложения в индустрии HFT всегда использовали эту схему. Поэтому CPU% не является тем показателем, которым он был раньше.
Это еще один пример мифа о производительности, который никогда не был правдой, хотя мы никогда не обладали такими возможностями мониторинга MC, как сегодня. Убедитесь, что вы отслеживаете использование MC. Вы будете удивлены, сколько странных аномалий производительности это позволит обнаружить.
Миф №3. Семплирующие профилировщики отлично работают в многопоточных приложениях
В наши дни у каждого представителя индустрии есть свой любимый семплирующий профилировщик. Они все более просты в использовании, требуют минимальных накладных расходов и предлагают все виды графических пользовательских интерфейсов для интуитивной навигации. Просто запустите его и посмотрите на порядок убывания функций, нагружающих ваш процессор больше всего. Затем вы начнете устранять неполадки с самого верха списка. Легкий день в офисе.
Но подождите! Эта схема работает только для однопоточных приложений. Когда вы имеете дело с многопоточными приложениями, такой порядок убывания функций с высоким потреблением ЦП может увести вас по ложному пути. На самом деле функции, потребляющие больше всего процессора, могут работать в потоках, которые никак не влияют на производительность критического пути. Чарли Курцингер и Эмери Бергер писали об этом недостатке профилировщика для многопоточных программ. И они придумали умную технику для его устранения: Causal Profiling.
Causal Profiling включает в себя проведение множества экспериментов во время рантайма приложения для определения критических путей исходных строк с помощью техники, называемой “виртуальным ускорением”. По завершении этих экспериментов выводится оценка причинно-следственной связи. Например, “оптимизация строки № 38 в функции X на 5% повысит общую производительность приложения на 22%”. И это не просто ерунда из области фантастики - сегодня это уже существует в виде инструмента. Он называется COZ, и это один из самых надежных инструментов в моем личном арсенале.
Однажды я использовал его на одном из мероприятий, где COZ определил, что основная проблема в флагманском приложении существовала в потоке, который, как клялась команда разработчиков, имел нулевое влияние на критический путь. В итоге COZ оказался прав.
В следующий раз, когда вы будете профилировать многопоточное приложение, сравните результаты, полученные с помощью вашего любимого семплирующего профилировщика, с результатами, полученными с помощью COZ. Несколько подобных экспериментов сами по себе развеют этот миф.
Миф №2. Тактовая частота процессора имеет первостепенное значение
Некоторым из вас это может показаться очевидным. Но я столкнулся с этим мифом достаточно недавно, чтобы поставить его на второе место в списке просто за его впечатляющую живучесть. В команде из 10 разработчиков хотя бы один считает, что процессор A от поставщика A быстрее, чем процессор B от поставщика B, если у процессора A быстрее тактовая частота. Несколько разработчиков считают, что процессор E быстрее более нового процессора G от того же производителя, если у процессора E больше тактовая частота. Потому что, в конце концов, они оба происходят от одного и того же производителя.
Много лет назад я работал в компании, где ведущий инженер-программист одной из групп отказывался переходить на новейшую архитектуру Broadwell, потому что ее тактовая частота была гораздо ниже, чем у его старых систем Sandy Bridge Workstation. Когда я убедил его попробовать Broadwell, эффект от снижения задержек в его торговом алгоритме просто ошеломил его.
Возможно, в самом начале развития процессоров в этом мифе и была доля правды. Но с появлением конвейерных, суперскалярных процессоров со все более сложной микроархитектурой тактовая частота превратилась лишь в один из элементов в огромном списке факторов, определяющих общую производительность. Сбой в законе масштабирования Деннарда делает эту точку зрения еще более актуальной, поэтому большее число ядер на процессор больше, чем более высокая тактовая частота.
Хотите узнать, сколько лет этому мифу о производительности? Вот короткое видео 2001 года, посвященное тому, что тогда называлось “мифом о мегагерцах”. Да, вы правильно поняли… мегагерц.
8-минутный ролик Джона Рубенштейна, в котором он развенчивает миф о мегагерцах, сравнивая G4 с Pentium 4
№1. Сложность Big O == Производительность
Выбросьте книги по структурам данных и алгоритмам. Смотрите научные работы и делайте замеры. Это все, что мы можем. Книги довольно сильно устарели.
Andrei Alexandrescu
Разработчики выходят из школы с пониманием того, как вычислить и выразить в нотации Big O временную сложность алгоритма. Этот алгоритм константный (O(1)), этот - линейный (O(N)), этот - логарифмический (O(log N)) и так далее. Неявно в этой нотации Big O присутствует константа C, которая представляет машинные эффекты, такие как кэш процессора, эффекты ветвления и т. д. Каковы общие рекомендации относительно этой константы C в большинстве учебников по курсу “Алгоритмы”?
Когда мы используем нотацию Big-O, мы опускаем константы и члены низшего порядка. Это происходит потому, что когда размер задачи N становится достаточно большим, эти члены не имеют значения.
И здесь кроется проблема: Где находится граница, за которой N становится “достаточно большим” для данной задачи? До этого момента разница в константе C может привести к тому, что алгоритм O(N²) превзойдет конкурирующий алгоритм O(N log N). Курсы в колледже должны больше подчеркивать влияние машинных эффектов, таких как кэширование процессора, и преимущества профилирования для них.
Особенно интересной презентацией, иллюстрирующей это, является CppCon 2019 Keynote Александреску, ссылка на которую приведена ниже. В нем он рассказывает о своих попытках улучшить сортировку вставки на сотнях элементов. Хотя в первых попытках ему удалось существенно сократить количество операций, это неожиданно привело к регрессиям во время выполнения:
На современных процессорах выполнение большего количества работы (даже если в конечном итоге она отбрасывается) может привести к повышению производительности, несмотря на алгоритмическую сложность. Этот миф о том, что анализ сложности алгоритмов равен анализу производительности, должен исчезнуть, и как можно скорее!
Присоединяйтесь к борьбе с мифами
Хотя эти 5 мифов - самые распространенные из тех, с которыми я сталкивался в последнее время, возможно, вы встречали и другие упрямо живущие мифы. Не закрывайте глаза! Развенчайте их, пока они не распространились, как вирус, и не заразили следующее поколение технарей. И я открою вам небольшой секрет.. некоторые из самых больших распространителей супермифов будут вашими самыми близкими и опытными коллегами!
The call is coming from inside the house!!!
Комментарии в Telegram-группе!