Что заставляет ядро ​​потреблять процессор на page_fault?

оборудование/ОС: Linux 4.9, 64G RAM.

Работает 16 демонов. Каждое чтение случайных коротких (100 байт) фрагментов файла размером 5 ГБ обращается к нему как к памяти, отображаемой через mmap() при запуске демона. Каждый демон читает свой собственный файл, всего 16 файлов по 5 ГБ.

Каждый демон делает примерно 10 операций чтения в секунду. Не слишком много, нагрузка на диск довольно маленькая.

Иногда (1 событие за 5 минут, без периода, совершенно случайно) какой-то случайный демон застрял в коде ядра со следующим стеком (см. рисунок) на 300 миллисекунд. Это не коррелирует с крупными неисправностями: крупные неисправности идут с постоянной скоростью около 100...200 в секунду. Чтение диска также постоянно.

Что может быть причиной этого?

стек получен с перфорированной записью

Текст изображения: __list_del_entry isolate_lru_pages.isra.48 shrink_inactive_list shrink_node_memcg shrink_node node_reclaim get_page_from_freelist enqueue_task_fair sched_clock __alloc_pages_nodemask alloc_pages_vma handle_mm_fault __do_page_fault page_fault


person pavelkolodin    schedule 15.10.2020    source источник
comment
Итак, вы уверены, что это была единственная ошибка программной страницы, которая остается в ядре в течение 300 мс? Можете ли вы сказать, становится ли свободный список огромным или фрагментированным или что-то в этом роде? Я не думаю, что прозрачные огромные страницы подходят для mmap с файловой поддержкой, поэтому, вероятно, ваша настройка /sys/kernel/mm/transparent_hugepage/defrag не должна иметь значения, если только она не выбирает этот момент для дефрагментации анонимных страниц для другого процесса? Или, если это ошибка на анонимной странице, отдельно от используемых вами сопоставлений на основе файлов.   -  person Peter Cordes    schedule 16.10.2020
comment
Ошибка программной страницы @PeterCordes - не знаю, что такое ошибка программной страницы. Я не знаю, с какой ошибкой страницы я имею дело. если свободный список становится огромным или фрагментированным - я не знаю, как это понять. /sys/kernel/mm/transparent_hugepage/defrag — спасибо за это. Я не знаю, как найти ответ на большинство ваших вопросов.   -  person pavelkolodin    schedule 16.10.2020
comment
@PeterCordes я думаю, что madvise(MADV_RANDOM) решил проблему.   -  person pavelkolodin    schedule 16.10.2020
comment
Ах, ядро ​​пыталось выполнить предварительную проверку / упреждающее чтение с диска, задерживая обработку ошибки для фактической страницы, которую вы коснулись? Re: программная ошибка страницы, см. en.wikipedia.org/wiki/Page_fault#Minor в отличие от основного/жесткого (требуется ввод-вывод) или недопустимого (segfault).   -  person Peter Cordes    schedule 16.10.2020
comment
@PeterCordes кажется, что однажды мое решение сработало. После перезапуска приложения все стало плохо работать   -  person pavelkolodin    schedule 20.10.2020


Ответы (1)


У вас в стеке есть функции shrink_node и node_reclaim. Они вызываются для освобождения памяти (которая отображается как buff/cache инструментом командной строки free): https://www.kernel.org/doc/html/latest/admin-guide/mm/concepts.html#reclaim

Процесс освобождения восстанавливаемых страниц физической памяти и их перепрофилирования называется (сюрприз!) восстановлением. Linux может освобождать страницы либо асинхронно, либо синхронно, в зависимости от состояния системы. Когда система не загружена, большая часть памяти свободна, и запросы на выделение будут немедленно удовлетворены за счет наличия свободных страниц. По мере увеличения нагрузки количество свободных страниц уменьшается, и когда оно достигает определенного порога (верхнего предела), запрос на выделение пробуждает демон kswapd. Он будет асинхронно сканировать страницы памяти и либо просто освобождать их, если данные, которые они содержат, доступны в другом месте, либо вытеснять их на резервное устройство хранения (помните эти грязные страницы?). По мере того, как использование памяти увеличивается еще больше и достигает другого порога — минимального водяного знака — выделение инициирует прямое восстановление. В этом случае выделение останавливается до тех пор, пока не будет высвобождено достаточное количество страниц памяти для удовлетворения запроса.

Таким образом, ваша система с 64 ГБ ОЗУ имеет ситуацию, когда свободной памяти не осталось. Этого объема памяти достаточно для хранения копии 12 файлов по 5 ГБ каждый, а ваши демоны используют 16 файлов. Linux может считывать из файлов больше данных, чем требуется приложению с технологией Readahead (Linux readahead: меньше хитростей для большего, ols 2007 pp273-284, man 2 читать вперед). MADV_SEQUENTIAL также может включить этот механизм, https://man7.org/linux/man-pages/man2/madvise.2.html

   MADV_SEQUENTIAL

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

  MADV_RANDOM

Ожидайте ссылки на страницы в случайном порядке. (Следовательно, чтение вперед может быть менее полезным, чем обычно.)

Не уверен, как ваши демоны открывали и читали файлы, был ли для них активен MADV_SEQUENTIAL или нет (или этот флаг был добавлен glibc или любой другой библиотекой). Также может быть некоторый эффект от THP - Прозрачные огромные страницы https://www.kernel.org/doc/html/latest/admin-guide/mm/transhuge.html. Обычное ядро ​​​​4.9 выпущено в 2016 году, а расширение thp для файловых систем планировалось в 2019 году https://lwn.net/Articles/789159/, но если вы используете RHEL/CentOS, некоторые функции могут быть перенесены в форк ядра 4.9.

Вы должны периодически проверять вывод free и cat /proc/meminfo, чтобы проверить, как ваши демоны и упреждающее чтение ядра Linux используют память.

person osgx    schedule 17.10.2020
comment
Без MADV_SEQUENTIAL или MADV_RANDOM ядро ​​будет выполнять некоторое упреждающее чтение, но менее агрессивно, чем с MADV_SEQUENTIAL. Таким образом, дополнительное загрязнение от упреждающего чтения можно объяснить без включения MADV_SEQUENTIAL по умолчанию или чего-то еще. - person Peter Cordes; 17.10.2020