Перейти к содержимому 
Фрагментация памяти при работе сервера означает, что большие, непрерывные блоки больше не доступны, несмотря на свободную оперативную память, и критические выделения не работают. Я покажу причины, типичные симптомы и целевые контрмеры, чтобы Сервер реагируют расчетным путем, и распределение может быть надежно функция.
Центральные пункты
- Внутренний и внешний Различайте и конкретно рассматривайте фрагментацию.
- Распределитель приятелей понять: Заказы, разделения, недостающие слияния.
- Беговой лыжник-Правильно установите рабочие нагрузки, накладные расходы гипервизора и THP.
- Диагноз с метриками buddyinfo, vmstat и compaction.
- Схема распределения улучшить: Пулы, предварительное распределение, раздельное время жизни.
Что означает фрагментация памяти в повседневной работе сервера?
Я называю Память Фрагментация - это состояние, при котором свободная рабочая память разбивается на множество небольших участков, и большие запросы больше не получают непрерывную область. Внутренняя фрагментация возникает, когда выделенный блок больше, чем требуется на самом деле, и в нем остаются неиспользованные байты, что может привести к Эффективность уменьшается. Внешняя фрагментация возникает, когда свободные участки распределяются и больше не собираются вместе, образуя большую область, даже если в целом свободной оперативной памяти достаточно. Это именно тот случай, когда большие буферы, JIT-резервирование или драйверы, предпочитающие смежную память, терпят неудачу из-за кажущейся парадоксальной нехватки больших блоков. В хостинговых средах высокая параллельная нагрузка, длительное время работы и разнородные программные стеки усугубляют эту проблему. Динамика заметный.
Как Linux-Buddy-Allocator создает фрагментацию
Ядро Linux управляет физической памятью с помощью Бадди-аллокатор, который распределяет страницы по классам размеров (порядкам), начиная с 4 КБ. Если процессы запрашивают более крупные области, ядро разбивает большие блоки на приятелей до тех пор, пока не появится подходящий размер; при освобождении оно пытается объединить приятелей. Однако разная длина запросов, меняющееся время жизни и неравномерное освобождение препятствуют повторной сборке и способствуют появлению внешних блоков. Фрагментация. Со временем запас крупных заказов опустошается, а мелкие заказы увеличиваются - в /proc/buddyinfo появляются большие числа в низких заказах и нули в высоких заказах. С этого момента уплотнение и, возможно, поведение OOM вмешиваются чаще, что создает задержки и увеличивает сбои.
Причины в средах хостинга и виртуализации
Длительные рабочие нагрузки в Интернете и базах данных создают переменную схему распределения, которая разбивает большие блоки и позволяет впоследствии Объединить предотвращено. Фреймворки и библиотеки, которые освобождают память с опозданием или несогласованно, оставляют пробелы, в которых могут уместиться только небольшие запросы. Виртуализация добавляет свои собственные накладные расходы и перекладывает распределение памяти на гостевой сервер и гипервизор, что означает, что внешние Фрагментация создается быстрее. Неправильно установленные значения vm.min_free_kbytes увеличивают нагрузку, поскольку ядро имеет слишком мало буферов для атомарных выделений или чрезмерно их резервирует. Больше прозрачности о Виртуальная память помогает мне аккуратно организовать взаимодействие между гостевым аллокатором, THP, Huge Pages и гипервизором.
Влияние на производительность и пользовательский опыт
Если резервуар разделен на множество маленьких островков, то Задержки, потому что ядро чаще сжимается и смещается, прежде чем успевает обработать большие запросы. Приложения, которым требуются непрерывные области - например, базы данных, кэши или мультимедийные конвейеры, - быстрее выходят из строя. Несмотря на „свободную“ оперативную память, большие выделения не работают и вызывают сообщения об ошибках, перезагрузки или жесткие отмены, что может привести к нарушению сеансов и Транзакции нарушена. Фоновые действия, такие как уплотнение, увеличивают нагрузку на процессор и нагрузку на ввод-вывод, в результате чего даже легкие рабочие нагрузки кажутся более медленными. В сценариях хостинга это проявляется в длительном времени отклика, спорадических тайм-аутах и ухудшении масштабирования во время пиковых нагрузок.
Диагностика: от buddyinfo до метрик уплотнения
Сначала я проверяю /proc/buddyinfo, чтобы узнать, какие Заказы vmstat и sar показывают, как часто ядро уплотняет данные и стал ли активным путь OOM, что указывает на давление со стороны больших распределений. Я использую perf и strace, чтобы определить, ожидают ли потоки прямого уплотнения, и поэтому время отклика колеблется, что заметно в журналах и метриках. В средах с серверами Windows я визуализирую фрагментированные кучи с помощью инструментов отладки, чтобы проверить наличие больших разрывов и точно настроить параметры кучи. настроить. Я также измеряю самый большой свободный блок, потому что сумма свободной оперативной памяти недостаточна для диагностики.
Настройка ядра и виртуальных машин на практике
Я устанавливаю vm.min_free_kbytes умеренно выше, часто в коридоре 5-10 % оперативной памяти, чтобы ядро имело большие, атомарные Запросы может работать надежно. Я активирую прозрачные огромные страницы с осторожностью: либо по требованию, либо через madvise, в зависимости от профиля нагрузки и риска фрагментации. Статические огромные страницы обеспечивают предсказуемость, но требуют правильного планирования, чтобы не создавать проблем в других местах. Узкие места для создания порядка. Уплотнение вызывает порядок в краткосрочной перспективе, но не заменяет структурного решения для постоянных, нестабильных паттернов. Я включаю в настройку топологии NUMA, чтобы большие распределения оставались локальными и не расходились по узлам.
| Настройка | Цель | Выгода | Подсказка |
|---|---|---|---|
| vm.min_free_kbytes | Резерв для крупных ассигнований | Меньше пиков OOM/компактов | Постепенно увеличивайте и измеряйте значение |
| THP (на/советуйте) | Отдавайте предпочтение большим страницам | Меньше фрагментации, лучшая скорость TLB | Обратите внимание на задержки в работе |
| Огромные страницы (статический) | Резервные сплошные участки | Предсказуемые крупные блоки | Заранее планируйте пропускную способность |
| Уплотнение | Соедините свободные зоны | Временно увеличенные блоки | В краткосрочной перспективе увеличивает CPU/I&O |
| NUMA-Политика | Безопасное локальное распределение | Меньше задержек, меньше перекрестных трафиков | Настройка балансировки |
Зоны хранения, типы миграции и почему „неподвижный“ блокирует все.
Распределитель страниц работает не только с заказами, но и с зоны (DMA, DMA32, Normal, Movable) и Перенос типов (ПОДВИЖНЫЕ, НЕПОДВИЖНЫЕ, ВОССТАНАВЛИВАЕМЫЕ). Гранулами для этого являются „страничные блоки“. Как только в страничный блок попадают НЕПОДВИЖНЫЕ страницы (например, структуры ядра, страницы, прикрепленные драйверами), ядро помечает этот блок как трудноперемещаемый. Именно такие „загрязненные“ блоки не позволяют Compaction объединять свободные области в большие смежные блоки. Области формы. Поэтому я сознательно планирую емкость в ZONE_MOVABLE (где это возможно) и слежу за тем, чтобы данные приложений преимущественно распределялись как MOVABLE. Это означает, что большие, смежные резервы с большей вероятностью останутся доступными. Для рабочих нагрузок с высокими требованиями к DMA я использую целевое резервирование, чтобы страницы UNMOVABLE не разрушали широкую нормальную зону.
Чистый дизайн шаблонов распределения
Я группирую требования к хранению в соответствии с Срок службыкороткоживущие объекты в пулах, долгоживущие - в отдельных регионах, чтобы релизы не разрывали все подряд. Я группирую частые размеры в фиксированные пулы, чтобы уменьшить колебания порядка и разгрузить приятельский аллокатор. Я заранее планирую большие буферы на старте, а не запрашиваю их в середине трафика, что позволяет избежать пиков нагрузки при объединении. Я адаптирую запросы на выравнивание к реальным потребностям, потому что чрезмерное выравнивание тратит место и способствует внутреннему Фрагментация. В конвейерах сборки и развертывания я тестирую пути хранения со сценариями нагрузки до того, как трафик поступит в реальном времени.
Выбор аллокатора в пользовательском пространстве: glibc, jemalloc, tcmalloc
Не всякая фрагментация является проблемой ядра. Сайт Пользовательское пространство-аллокатор оказывает большое влияние на шаблон, который в конце видит buddy-аллокатор. glibc malloc использует арены для каждого потока; на многих ядрах это может привести к высокой внутренней фрагментации. Я ограничиваю количество арен и обрезаю их более агрессивно, чтобы неиспользуемые области быстрее возвращались в операционную систему. Альтернативы, такие как jemalloc или tcmalloc, предлагают более тонкие классы размеров и более последовательные схемы совместного использования, что может заметно снизить внешнюю фрагментацию. Решающим фактором является: Я провожу измерения в условиях производственной нагрузки, поскольку каждый аллокатор имеет различные компромиссы в отношении задержки, пропускной способности и занимаемой памяти. Для сервисов с высокой пропускной способностью и однородными размерами объектов выделенные арены или пулы типа slab часто обеспечивают наиболее стабильную производительность. Задержки.
Меры на стороне приложения: Java, PHP, кэши и базы данных
В Java я использую Аренас или региональный аллокатор и выбирайте профили GC, которые предпочитают большие, смежные резервирования вместо постоянного разбиения кучи на мелкие кусочки. Я балансирую Xms/Xmx так, чтобы куча не увеличивалась и не уменьшалась постоянно, поскольку это способствует появлению дыр. Для стеков PHP и MySQL я использую фиксированные пулы памяти, ограничиваю негабаритные объекты и оптимизирую размеры буферов с целью достижения согласованных шаблонов выделения. Оптимизация PHP/MySQL. Я организую системы кэширования (например, объектные или страничные кэши) для равномерного размера кусков, чтобы релизы не оставляли больших пробелов постоянно. Если ничто другое не помогает, я планирую контролируемые перезапуски в окна обслуживания вместо того, чтобы рисковать незапланированными событиями OOM, которые могут привести к краху всей системы. Услуги отменить.
Практика работы с контейнерами и Kubernetes
Контейнеры не изменяют функциональность Бадди-аллокаторы - они только сегментируют представления и лимиты. Поэтому фрагментация остается проблемой хоста, но проявляется в стручках через выселения, колебания задержек или затраты на разделение THP. Я добиваюсь стабильности, используя:
- Установите классы QoS (Guaranteed/Burstable), чтобы критические стручки получали фиксированные резервы и не росли и не сокращались одновременно.
- реалистичные ограничения памяти, чтобы обрезка и возврат не нарушали жесткие границы Границы столкнуться.
- THP/Hugepages последовательно распространяются по всему хосту и предоставляют подсистемам, которым нужны большие страницы, статически зарезервированные пулы.
- Используйте стратегии разминки (предварительный отказ, предварительное распределение), чтобы большие блоки были заняты раньше и не запрашивались позже под нагрузкой.
Я слежу за контейнерными узлами, как за "голым металлом": buddyinfo, события уплотнения, убийства OOM - только я также соотношу их с перезагрузками и выселениями стручков, чтобы точно отделить причину.
Виртуализация, NUMA и влияние аппаратного обеспечения
Среди гипервизоров я проверяю, как взаимодействуют гостевой аллокатор, раздувание и хост THP, поскольку наслоение может увеличить фрагментацию и создать большие Блоки делает его дефицитным. Я постоянно наблюдаю топологии NUMA: локальное распределение снижает задержки и предотвращает распределение больших запросов по узлам и, следовательно, уменьшение их объема. Там, где это имеет смысл, я прикрепляю рабочие нагрузки к узлам NUMA и наблюдаю за влиянием на количество ошибок страниц и обращений к TLB. Для более тонкого контроля я устанавливаю рекомендации для узлов хранения и вытягиваю Балансировка NUMA целенаправленно. Я также включаю обновления прошивки и микрокода, чтобы исключить неожиданные побочные эффекты и обеспечить предсказуемость при использовании крупных Требования получить.
Драйвер устройства, DMA и CMA
Водители, которые физически когерентный области (например, некоторые DMA-движки, мультимедиа, карты захвата) усиливают внешнюю фрагментацию. Здесь я планирую использовать распределитель смежной памяти (CMA) или резервировать большие блоки на ранней стадии загрузки. Это не позволит множеству мелких выделений „прогрызть“ адресное пространство до того, как драйвер получит свои буферы. В то же время я изолирую страницы с буферами (например, с помощью RDMA/DPDK) от общей памяти приложений, чтобы их символ UNMOVABLE не приводил в негодность целые блоки страниц. Мне также следует проверить, достаточно ли конфигурации IOMMU виртуализируют большие, несмежные области - в противном случае мне нужны специальные резервы и четкие временные ограничения. Windows для этих ассигнований.
Эксплуатационная рутина: разумно используйте окна мониторинга и обслуживания
Я вставляю снимки buddyinfo, счетчики уплотнений и события OOM в свои Мониторинг, чтобы видеть тенденции, а не отдельные события. Я уменьшаю количество скользящих развертываний, чтобы колебания памяти были сосредоточены во временных окнах, а остальная часть недели проходила более гладко. Во время окон обслуживания я вручную запускаю уплотнение, если это необходимо, очищаю кэш и перезапускаю службы, пока фрагментация не стала причиной проблем с производительностью. Я сопоставляю журналы и метрики с пиковым трафиком, чтобы выявить повторяющиеся закономерности и соответствующим образом настроить буферы. При крупных изменениях я сначала тестирую их в режиме постановки, чтобы не обнаружить неожиданных изменений. Побочные эффекты в процессе эксплуатации.
Runbook: Когда крупные распределения не работают сегодня
Если возникают острые сообщения об ошибках „распределение заказа X не удалось“, я работаю четко по шагам:
- Ситуационная картина: Сохраните buddyinfo, проверьте vmstat (allocstall/compact), найдите в dmesg записи Compaction/OOM. Оцените самый большой свободный блок (наивысший порядок с >0).
- Краткосрочное облегчение: Приостановите работу некритичных служб, дросселируйте нагрузку, целенаправленно очищайте кэш. Запускайте уплотнение вручную и временно отключайте THP Defrag, если оно в данный момент наносит ущерб.
- Целевая очистка: Восстановление больших, смежных буферов в определенных службах (контролируемый перезапуск) до наступления следующего пика.
- Увеличить резерв: vm.min_free_kbytes и водяной знак, чтобы обеспечить атомарное выделение в течение следующих нескольких часов; эффект жесткого монитор.
- Постоянное средство: Исправьте шаблоны распределения, введите пулы, перенесите предварительное распределение на начало, проверьте локализацию NUMA и настройте THP/Huge Pages должным образом.
Измеряемые переменные, SLO и сигналы тревоги
Я не только измеряю объемы оперативной памяти, но и определяю SLOs для распределяемости: „наивысший порядок с доступностью“, „время до успешного выделения большого объема“, „процент срыва уплотнения“. Из этого я извлекаю сигналы тревоги, которые бьют рано, до того, как пользователи увидят тайм-аут. Полезные ключевые показатели включают
- Количество свободных блоков в высоких порядках (например, ≥ Order-9) в минуту.
- Частота и продолжительность прямого уплотнения или ожидания рекультивации.
- Доля сконцентрированных/не сконцентрированных страниц по отношению к общему объему памяти.
- Доля успешных выделений больших объемов в нагрузочных тестах и после развертывания.
Я связываю эти показатели с временем выхода релизов, пиками трафика и изменениями конфигурации. Таким образом, я выявляю закономерности, в соответствии с которыми я могу проактивно шкала или перенести окно распределения.
Планирование мощностей и учет затрат
Я рассчитываю складскую маржу таким образом, чтобы обе Нормальная работа и фазы обслуживания с увеличением объема выделенной памяти. Вместо того чтобы обновлять все подряд, я сначала проверяю исправления шаблонов, потому что хорошая настройка часто приносит больше, чем дополнительная оперативная память. При увеличении емкости я планирую резервы для THP/огромных страниц, чтобы большие страницы не столкнулись с пиковыми нагрузками приложений. Консолидация на меньшем количестве, но более мощных хостов может уменьшить фрагментацию, если я правильно настрою NUMA и профили распределения. В итоге при уменьшении фрагментации я экономлю в евро, так как снижаю пиковые нагрузки на процессор и перегрузку ввода-вывода и более эффективно использую лицензии. использовать.
Краткое резюме
Фрагментация памяти происходит, когда множество выделений разной длины и размера соединяются вместе. Области и большие запросы впоследствии заканчиваются ничем. Я решаю проблему по трем направлениям: Настройка ядра/VM (vm.min_free_kbytes, THP/Huge Pages), лучшие схемы выделения (пулы, предварительное выделение, раздельное время жизни) и чистое управление операциями (мониторинг, обрезка по расписанию, дисциплина NUMA). Для диагностики я полагаюсь на /proc/buddyinfo, счетчики уплотнения и измерение самого большого свободного блока, поскольку чистые показатели оперативной памяти обманчивы. Я уделяю особое внимание виртуализации и гипервизорам, чтобы гость и хост не работали друг против друга, а большие Блоки резервирование на ранней стадии. Сочетание этих компонентов повышает предсказуемость, предотвращает сбои из-за OOM и обеспечивает более быструю реакцию - особенно в условиях роста трафика и объема данных.
