LINUX.ORG.RU

В ядро Linux добавлена возможность буферизированной работы с ФС без кеширования

 , ,


0

2

В master ядра Linux принята серия патчей, позволяющая отдельным программам работать с файловой системой без использования страничного кеша.

Современные NVMe устройства работают настолько быстро, что страничный кеш оказывается полностью заполнен в течении нескольких секунд, в результате чего начинается экстренный сброс данных на диск. После сброса данных круг повторяется заново. Такой цикл не позволяет достичь пика производительности диска, ведет к неоптимальному использованию памяти и непредсказуемым задержкам, что сказывается на работе как десктопных GUI приложений, так и баз данных, веб-серверов, и т.д.

В ядре уже существует возможность небуферизированного чтения/записи с помощью открытия файла с флагом O_DIRECT, однако от приложения требуется использовать выравненные блоки данных по 512 или 4096 байт (в зависимости от размера блока диска). Это делает затруднительным использование этой техники в таких приложениях как PostgreSQL.

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

По словам автора (Jens Axboe), ему удалось добиться увеличения производительности на 65% в тестовом сценарии, обеспечив предсказуемые задержки операций и заметно снизив нагрузку на CPU.

Чтобы использовать новую возможность, нужно установить флаг операции RWF_UNCACHED. Для приложений, использующих традиционные интерфейсы вроде read(3) и write(3), потребуется переход на функции preadv2(2) и pwritev2(2), т.к. только эти функции позволяют передавать флаги операций. Для приложений, использующих io_uring, достаточно выставить флаг в sqe->rw_flags. Таким образом, приложение может контролировать, какие данные нужно кешировать, а какие – нет.

Подробности

Перемещено dataman из kernel



Последнее исправление: gaylord (всего исправлений: 8)
Ответ на: комментарий от vbr

Это ты описал read cache. Он не содержит грязных страниц, их не надо писать на носитель. Поэтому переиспользовать их под что-то другое не проблема.

Тут в треде выше обсуждается writeback cache. В нем грязные страницы, ещё не сброшенные на носитель. Чтобы их переиспользовать, их надо сначала сбросить.

Может быть ядро вместо того, чтобы сбросить их на носитель, сбрасывает их в своп? Это был бы эпик фейл.

iliyap ★★★★★
()
Ответ на: комментарий от gaylord

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

iliyap ★★★★★
()
Ответ на: комментарий от iliyap

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

Так вот речь о том, что нет. Если у тебя сервер занят базой данных, которой кеширование скорее мешает, чем помогает, и ты включить nocache, то у тебя не будет бесполезного кеша и затрат на reclaim. В этом суть патча, убрать бессмысленный рекеш там, где это не нужно.

gaylord
() автор топика
Ответ на: комментарий от iliyap

Все страницы используются блочным кэшем. Так что reclaim (переиспользование) неизбежно.

А потом, вероятно, начнется другое интересное – у людей на сервере сидит база, которая nocache и nginx, которой не стал заморачиваться и cache. nginx будет забивать своими данными кеш, база опять будет страдать. Люди пойдут в ядро ныть, мол как так-то, nocache сделали, а не помогает. В ядре сперва долго будут спорить, а потом сделают ручку вроде «ограничить page cache сверху». Мне кажется оно как-то так будет.

gaylord
() автор топика
Ответ на: комментарий от gaylord

Те СУБД, у которых есть собственный кэш (MySQL/Innodb, Oracle, MSSQL) – они лочат кэш в памяти (чтоб его не свопили) и используют O_DIRECT (чтобы избежать двойного кэширования). У них нет проблем с системным кэшем. А пользователи Postgres видимо должны на хосте запускать только Postgres, раз он использует системный кэш.

iliyap ★★★★★
()
Ответ на: комментарий от iliyap

Те СУБД, у которых есть собственный кэш (MySQL/Innodb, Oracle, MSSQL) – они лочат кэш в памяти (чтоб его не свопили) и используют O_DIRECT (чтобы избежать двойного кэширования). У них нет проблем с системным кэшем.

Все так. Но дизайнить каждый раз собственную реализацию read-modify-write для каждого приложения, которому мешает системный кеш, кажется странным.

А пользователи Postgres видимо должны на хосте запускать только Postgres, раз он использует системный кэш.

А там ещё nginx, монга, minio, черт в ступе и все это сверху обмазано Docker’ом, потому что контейнеры.

gaylord
() автор топика
Ответ на: комментарий от firkax

Идут десятилетия, меняются компы, мощьности, архитектуры процессоров, а 12309 приобретает всё более изощрённый формы. Я вчера качал из интернета большой файл через небраузер. Интернет у меня медоенный. А браузером пользоваться было невозможно. Не просто страницы долго грузились, я вкладки переключать не мог. Я в файловом менеджере с чашечкой кофе делал перерывы, чтобы он открыл мне папочку. И всё что было запущено - ватсап, браузер, файловый менеджер и торрентокачалка. (Качал официальную музыку Самовара)

R_He_Po6oT ★★★★★
()