Эта статья выбрана из серии статей «Практика инфраструктуры Byte Beat».

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

На такие проблемы, как «всплеск задержки» и «дрожание производительности», обычно влияет множество факторов, и их неудобно исследовать. В этой статье в качестве примера рассматриваются онлайн-проблемы, чтобы подробно объяснить перестрелку TLB, что в конечном итоге снижает потребление ЦП примерно на 2%, устраняет джиттер скачками, и становится более стабильным.

фон проблемы

В процессе работы интернет-бизнеса неизбежно возникают такие проблемы, как "всплеск задержки" и "дрожание производительности". Обычно на такие проблемы влияют различные программные среды и даже аппаратные среды. Причины относительно неясны и относительно неясны. трудно решить.

В этой статье в качестве примера рассматривается онлайн-проблема, подробная архитектура x86 в сочетании со знаниями об управлении памятью ядра, дополненная различными инструментами отладки на платформах Linux, чтобы подробно объяснить проблему сбоя TLB и, наконец, решить проблему. и повысить эффективность бизнеса.

условность существительного

Ядро:Эта статья конкретно относится к Linux-4.14.

КВМ:Виртуальная машина на основе ядра. Одна из основных технологий виртуальных машин.

Хозяин:Относится к хосту в сценарии виртуализации.

Гость:Относится к виртуальной машине в сценарии виртуализации.

АПИК:Усовершенствованный программируемый контроллер прерываний. Контроллер прерываний, используемый процессорами Intel.

ЛАПИК:Локальный расширенный программируемый контроллер прерываний.

ИПИ:Межпроцессорное прерывание. Процессоры взаимодействуют друг с другом.

ММУ:Блок управления памятью. Аппаратное обеспечение, используемое ядром для управления отображением виртуальных и физических адресов.

TLB:Резервный буфер перевода. Кэш, используемый MMU для ускорения поиска в таблице страниц. Используется для увеличения скорости преобразования MMU.

ПТЭ:Запись таблицы страниц. Управление записями таблицы страниц, используемыми таблицами страниц.

Джемаллок:Библиотека управления памятью пользовательского режима malloc/free работает лучше, чем стандартная реализация glibc в многопоточных параллельных сценариях.

TLB shootdown

Как произошла стрельба TLB

Как показано на рисунке выше, процесс имеет4 темывыполнять параллельно. Поскольку 4 потока совместно используют таблицу страниц одного и того же процесса, во время выполнения загружая pgd в cr3,Одна и та же таблица страниц загружается в TLB каждого процессора..

Если вы хотите изменить таблицу страниц на CPU0, особенно если вы хотите освободить часть памяти, вам нужно изменить таблицу страниц,В то же время изменить свой собственный TLB(или перезагрузите TLB).

Однако этого недостаточно. Например, страница A освобождается на CPU0, а страница A освобождается ядром и, вероятно, будет использоваться другими процессами. но,Соответствующие записи PTE по-прежнему кэшируются в TLB CPU1, CPU2 и CPU3, и страница A по-прежнему доступна..

Чтобы этого не произошло,CPU0 должен уведомить CPU1, CPU2 и CPU3, а также отключить соответствующий PTE в TLB.. Способ уведомления заключается в использованииIPI(межпроцессорное прерывание).

В виртуализированном сценарии стоимость IPI относительно высока. Если в гостевой системе много IPI, вы увидите стремительный рост системного процессора гостевой системы. В то же время можно обнаружить, что виртуальная машина имеет внезапное увеличение vmexit на хосте, что в основном генерируется ICR-запросом wrmsr. (Студенты, знакомые с x86, знают, что в режиме x2apic реализация IPI на x86 заключается в запросе ICR через инструкцию wrmsr)

Как подтвердить, что проблема вызвана сбитием TLB

Выполнить в гостевой системе:

#watch -d -n 1 "cat /proc/interrupts | grep TLB"

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

Выполнить в гостевой системе:

#perf top

Если ты видишьsmp_call_function_many, то, к сожалению, он отправляет IPI партиями.

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

int madvise(void *addr, size_t length, MADV_DONTNEED);

Как проверить, что процесс использует jemalloc, jemalloc вызывает madvise, смотрите ниже:

# ls /proc/*/maps | xargs grep jemalloc

Независимо от того, действительно ли соответствующий процесс выполняет метод madvise, MADV_DONTNEED освободит запись в таблице страниц, что приведет к отключению tlb. Таким образом, MADV_DONTNEED — важная подсказка для решения проблемы с tlb:

# strace -f -p 1510 2>&1 | grep madvise

madvise MADV_DONTNEED и мунмап

После подтверждения вышеупомянутой проблемы со сбитием TLB, давайте еще раз рассмотрим, какую роль играет системный вызов madvise?

int madvise(void *addr, size_t length, MADV_DONTNEED);

Общий процесс выделения памяти

Используйте mmap для выделения виртуального адресного пространства;
При первом доступе к адресу в пределах 4 КБ MMU обнаруживает, что соответствующего PTE нет, и вызывает ошибку страницы;
Ядро выделяет соответствующую страницу.

Если используется DONTNEED, соответствующая страница будет освобождена. Если вы посетите снова в следующий раз, вышеуказанные 2 и 3 будут повторяться.

Эффект заключается в том, что после того, как короткая страница возвращается в ядро, следующий доступ перераспределяется.

Разница между madvise DONTNEED и munmap

Например, как показано в состоянии 0, процесс пользовательского режима выделяет два адресных пространства виртуальных машин, VMA0 и VMA1. Для некоторых адресов уже выделены физические страницы (например, 0x800000), а для некоторых еще не выделены (например, 0x802000).

Как показано в состоянии 1, когда процесс пользовательского режима получает доступ, например, к адресу 0x802000 в первый раз, он запускаетpage fault, ядро выделяет физическую страницу (адрес 0x202000) для 0x802000 процесса пользовательского режима.

Как показано в состоянии 2, выполняется:

madvise(0x800000, 8192, MADV_DONTNEED)

После этого ядро освобождает соответствующую физическую страницу. Затем в следующий раз, когда вы получите доступ к 0x800000 ~ 0x801fff, будет вызвана ошибка страницы. Обработка аналогична состоянию 1.

Как показано в состоянии 3, выполняется:

munmap(0x800000, 16384);

Освободите соответствующий VMA. Затем в следующий раз, когда вы получите доступ к 0x800000 ~ 0x803fff, он сработаетsegment fault. Поскольку адрес был освобожден и является недопустимым адресом, ядро отправит сообщение процессу.signal 11. В большинстве случаев процесс будет убит.

Решение проблем с TLB с помощью jemalloc ENV

Проблема возникает из-за jemalloc, поэтому попробуйте решить проблему из самого jemalloc.

Попробуйте обратиться к сообществу и спросить у сопровождающего jemalloc, есть ли способ решить проблему, вызванную перестрелкой TLB.Сопровождающий предлагает динамически контролировать, запускает ли jemalloc madvise через переменную окружения jemalloc (MALLOC_CONF). Вопросы и ответы см.

https://github.com/jemalloc/jemalloc/issues/1422

Пишите тестовый код локально и фактически тестируйте jemalloc (ближе к апстриму).5.0версия) и совет, данный сопровождающим, импортируйте переменные среды до запуска процесса:

MALLOC_CONF=dirty_decay_ms:-1,muzzy_decay_ms:-1

Можно убедиться, что проблемы можно успешно избежать. Эта переменная среды может решить проблему с tlb.Подробные функции параметров см. в руководстве:

http://jemalloc.net/jemalloc.3.html#opt.dirty_decay_ms

Бизнес также использует jemalloc, но тест не имеет никакого эффекта.

Для такой библиотеки динамических ссылок, фактически используемой бизнесом:

#strings libjemalloc.so.2 | grep -i version

Можно обнаружить, что фактическая используемая версия:

JEMALLOC_VERSION "4.2.0-0-gf70a254d44c8d30af2cd5d30531fb18fdabaae6d"

При чтении исходного кода jemalloc было обнаружено, что в версии 4.2 переменные параметры, заданные сопровождающим, не поддерживаются. Но аналогичного эффекта можно добиться со следующими переменными:

MALLOC_CONF=purge:decay,decay_time:-1

После настройки параметров jemalloc производительность бизнеса значительно улучшилась. Как показано на рисунке ниже, сравнивая последнюю нулевую точку с предыдущей нулевой точкой, джиттер ЦП значительно улучшился: от предыдущего джиттера около 6% до стабильной работы менее 4%, а потребление ЦП кривая более стабильная и плавная.

В то же время задержка в бизнесе также более стабильна, а PCT99 также снижает скачок задержки.

напиши в конце

В процессе решения проблемы не так упорядоченно, как написано в статье. В этот период я также использовал perf для наблюдения за изменением функций хотспота, использовал atop для сравнения производительности бизнеса и системных показателей до и после, также наблюдал данные виртуализированного мониторинга (количество wrmsr) и т. д. для устранения помех и блокировать проблему шаг за шагом.

По мере увеличения сложности современных операционных систем возрастает и сложность проблемы. В процессе решения задач мы также добиваемся прогресса!

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

поделиться больше

ByteDance самостоятельно разработала графовую базу данных триллионов уровней и практику графовых вычислений

Практика ByteDance HDFS уровня EB

Команда инфраструктуры ByteDance

Команда инфраструктуры ByteDance — важная команда, которая поддерживает бесперебойную работу множества пользовательских продуктов ByteDance, включая Douyin, Today's Toutiao, Xigua Video и Volcano Small Video, Стабильная разработка обеспечивает гарантии и импульс.

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

В культурном плане команда активно использует открытый исходный код и инновационные аппаратные и программные архитектуры. Мы давно набираем студентов по направлению инфраструктура, подробнее см.job.bytedance.com, заинтересованные могут обращаться по электронной почте arch-graph@bytedance.com .

Добро пожаловать в техническую команду ByteDance