Почему моя система Linux заикается, если я постоянно отбрасываю кэши?

за последние несколько месяцев у меня была чрезвычайно раздражающая проблема с моей системой Linux: она заикается при воспроизведении звука Firefox, движении мыши и т. д., с крошечным секундным (но все еще заметным) заиканием каждые несколько секунд. Проблема усугубляется по мере заполнения кэша памяти или при запуске программ, интенсивно использующих диск/память (например, backup software restic). Однако, когда кэш не заполнен (например, при очень небольшой нагрузке), все работает очень гладко.

просмотр через perf top вывод, я вижу, что list_lru_count_one имеет высокие накладные расходы (~20%) в эти периоды задержки. htop также показывает kswapd0 использование 50-90% CPU (хотя кажется, что влияние намного больше). Во времена крайнего отставания,htop CPU meter часто доминирует использование процессора ядра.

единственный обходной путь, который я нашел, - это либо заставить ядро сохранить свободную память (sysctl -w vm.min_free_kbytes=1024000) или непрерывно сбрасывать кэши памяти через echo 3 > /proc/sys/vm/drop_caches. Не идеально, конечно, и ни один полностью не решает заикание либо; это только делает его менее частым.

у кого-нибудь есть идеи, почему это может происходить?

Сведения О Системе

  • i7-4820k с 20 ГБ (несогласованной) оперативной памяти DDR3
  • воспроизводится на Linux 4.14-4.18 на NixOS unstable
  • запускает контейнеры Docker и Kubernetes в фоновом режиме (что, по моему мнению, не должно создавать микростаттеринг?)

что у меня есть уже пробовал

  • изменение планировщики ввода-вывода (значения), используя multiqueue планировщики ввода-вывода
  • С помощью -ck набор патчей от Con Kolivas (не помогло)
  • отключение swap, изменение swappiness, используя zram

EDIT: для ясности, вот изображение htop и perf в ходе такой ЛАГ Спайк. Обратите внимание на высокий list_lru_count_one загрузка процессора и kswapd0 + ЦП высокий ядра использование.

htop and perf output

25
задан Pneumaticat
10.01.2023 6:14 Количество просмотров материала 2796
Распечатать страницу

2 ответа

похоже, вы уже пробовали многие вещи, которые я бы предложил сначала (настройка конфигурации подкачки, изменение планировщиков ввода-вывода и т. д.).

помимо того, что вы уже пробовали изменить, я бы предложил изучить возможность изменения некоторых значений по умолчанию для обратной записи VM. Это управляется следующими шестью значениями sysctl:

  • vm.dirty_ratio: определяет, сколько записей должно быть отложено для обратной записи, прежде чем она будет вызванный. Обрабатывает обратную запись переднего плана (для каждого процесса) и выражается в виде целого процента оперативной памяти. По умолчанию 10% оперативной памяти
  • vm.dirty_background_ratio: определяет, сколько записей должно быть отложено для обратной записи, прежде чем она будет запущена. Обрабатывает фоновую (общесистемную) обратную запись и выражается в виде целого процента оперативной памяти. По умолчанию 20% оперативной памяти
  • vm.dirty_bytes: как vm.dirty_ratio, за исключением выраженного как общее количество байт. Либо это или vm.dirty_ratio будет используется, в зависимости от того, что было написано последним.
  • vm.dirty_background_bytes: как vm.dirty_background_ratio, за исключением выраженного как общее количество байт. Либо это или vm.dirty_background_ratio будет использоваться, в зависимости от того, что было написано последним.
  • vm.dirty_expire_centisecs: сколько сотых доли секунды должно пройти до начала отложенной обратной записи, если указанные выше четыре значения sysctl еще не запустили бы ее. По умолчанию 100 (одна секунда).
  • vm.dirty_writeback_centisecs: как часто (в сотых долях секунды) ядро будет оценка грязных страниц для обратной записи. По умолчанию 10 (одна десятая секунды).

таким образом, со значениями по умолчанию, каждая десятая секунды, ядро будет делать следующее:

  • запишите все измененные страницы в постоянное хранилище, если они были изменены более секунды назад.
  • запишите все измененные страницы для процесса, если общий объем не записанной измененной памяти превышает 10% оперативной памяти.
  • пишите все измененные страницы в системе, если общий объем не записанной измененной памяти превышает 20% оперативной памяти.

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

общее мнение в эти дни, чтобы приспособиться vm.dirty_ratio быть 1% ОЗУ, и vm.dirty_background_ratio быть 2%, что для систем с менее чем 64 ГБ оперативной памяти приводит к поведению, эквивалентному тому, что первоначально предполагалось.

некоторые другие вещи, чтобы смотреть на:

  • попробуйте увеличить vm.vfs_cache_pressure sysctl немного. Это определяет, насколько активно ядро освобождает память из кэша файловой системы, когда ему требуется ОЗУ. Значение по умолчанию-100, не опускайте его ниже 50 (you будет вам действительно плохое поведение, если вы идете ниже 50, в том числе Условия OOM), и не поднимайте его намного больше, чем около 200 (намного выше, и ядро будет тратить время на то, чтобы восстановить память, которую оно действительно не может). Я обнаружил, что увеличение его до 150 на самом деле заметно улучшает отзывчивость, если у вас достаточно быстрое хранение.
  • попробуйте изменить режим перегрузки памяти. Это можно сделать, изменив значение vm.overcommit_memory sysctl. По умолчанию, ядро будет использовать эвристический подход, чтобы попытаться предсказать, сколько оперативной памяти на самом деле может позволить себе совершить. Установка этого значения в 1 отключает эвристику и говорит ядру действовать так, как будто оно имеет бесконечную память. Установка этого значения в 2 говорит ядру не фиксировать больше памяти, чем общий объем пространства подкачки в системе плюс процент от фактического ОЗУ (контролируется vm.overcommit_ratio).
  • попробуйте настроить vm.page-cluster sysctl. Это определяет, сколько страниц будет заменено или выгружено одновременно (это логарифмическое значение base-2, поэтому значение по умолчанию 3 переводится на 8 страниц). Если вы фактически подкачка, это может помочь улучшить производительность подкачки страниц и из.
2
отвечен Austin Hemmelgarn 2023-01-11 14:02

проблема найдена!

оказывается, это проблема производительности в Linux Memory reclaimer, когда есть большое количество контейнеров / cgroups памяти. (Отказ от ответственности: мое объяснение может быть ошибочным, я не разработчик ядра.) Проблема была исправлена в 4.19-rc1+ в этот патч:

этот patcheset решает проблему с медленным shrink_slab (), возникающего на машины, имеющие много термоусадочных модулей и контрольных групп памяти (т. е. стеклотара.) Проблема в сложности shrink_slab () - O (n^2) и он растет слишком быстро с ростом количества контейнеров.

препятствуйте нам иметь 200 контейнеров, и каждый контейнер имеет 10 держателей и 10 контрольные группы. Все контейнерные задачи изолированы и не касаются внешних крепления контейнеров.

в случае глобального освобождения, задача перебрать все за memcgs и чтобы вызвать всех психиатров, знающих memcg, для всех них. Это означает, что задачи посетите 200 * 10 = 2000 термоусадочные для каждого memcg, и с есть 2000 memcgs, общее количество вызовов do_shrink_slab () 2000 * 2000 = 4000000.

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

мои шаги по устранению неполадок, в случае, если они полезны для тех, кто сталкивается с подобными проблемами:

  1. уведомления kswapd0 использование тонны процессора, когда мой компьютер заикается
  2. попробуйте остановить контейнеры Docker и снова заполнить память → компьютер не заикается!
  3. Run ftrace (после великолепный объяснение Блог Джулии Эван) чтобы получить след, смотри kswapd0 имеет тенденцию застревать в shrink_slab,super_cache_count и list_lru_count_one.
  4. Google shrink_slab lru slow найти набор патчей!
  5. переключитесь на Linux 4.19-rc3 и убедитесь, что проблема устранена.
0
отвечен Pneumaticat 2023-01-11 16:19

Постоянная ссылка на данную страницу: [ Скопировать ссылку | Сгенерировать QR-код ]

Ваш ответ

Опубликуйте как Гость или авторизуйтесь

Имя
Вверх