Рекомендации по кэшированию в файловых системах Linux для Azure NetApp Files

Статья
08/30/2024

В этой статье приведены рекомендации по кэшированию файловых систем для Azure NetApp Files.

Настраиваемые параметры кэша файловой системы

Необходимо понимать следующие факторы, связанные с настраиваемыми параметрами кэша файловой системы:

Запись на диск "грязного" буфера приводит к тому, что данные в чистом состоянии можно использовать для чтения в будущем, пока нехватка памяти не приведет к вытеснению.
Существует три триггера для асинхронной операции очистки:
- На основе времени: когда буфер достигает возраста, определенного в этом параметре, он должен быть помечен для очистки (т. е. освобождения или записи в хранилище).
- Нехватка памяти: дополнительные сведения см. в vm.dirty_ratio | vm.dirty_bytes.
- Закрытие: при закрытии дескриптора файла все "грязные" буферы асинхронно записываются в хранилище.

Эти факторы контролируются четырьмя настраиваемыми параметрами. Каждый параметр можно настроить динамически или постоянно с помощью tuned или sysctl в файле /etc/sysctl.conf. Настройка этих переменных повышает производительность приложений.

Примечание.

Сведения, обсуждаемые в этой статье, были обнаружены во время упражнений по проверке SAS GRID и SAS Viya. Таким образом, параметры основаны на уроках, полученных в упражнениях при проверке. Многие приложения также получают преимущества настройки этих параметров.

`vm.dirty_ratio | vm.dirty_bytes`

Эти два параметра определяют объем ОЗУ, доступный для данных, которые уже изменены, но еще не записаны в стабильное хранилище. При настройке одного параметра для другого автоматически указывается значение 0. Red Hat не рекомендует вручную устанавливать для любого из этих параметров значение 0. Параметр vm.dirty_ratio (по умолчанию) устанавливается Red Hat как 20 % или 30 % от физической памяти в зависимости от ОС. Это много, учитывая объем памяти современных систем. Можно установить vm.dirty_bytes вместо vm.dirty_ratio, чтобы обеспечить больше согласованности независимо от размера памяти. Например, в ходе текущей работы с SAS GRID определено, что 30 МиБ — это подходящий параметр для оптимальной производительности смешанной рабочей нагрузки.

`vm.dirty_background_ratio | vm.dirty_background_bytes`

Эти параметры определяют начальную точку, где механизм обратной записи Linux начинает записывать "грязные" блоки в стабильное хранилище. Red Hat по умолчанию устанавливает 10 % физической памяти, что в большой системе памяти является значительным объемом данных для начала записи на диск. При использовании SAS GRID в качестве примера рекомендация была установлена vm.dirty_background в 1/5 размера vm.dirty_ratio или vm.dirty_bytes. Принимая во внимание, как активно параметр vm.dirty_bytes устанавливается для SAS GRID, конкретное значение не задается.

`vm.dirty_expire_centisecs`

Этот настраиваемый параметр определяет, насколько старым может быть "грязный" буфер, прежде чем его необходимо пометить для асинхронной записи. Пример — рабочая нагрузка CAS для SAS Viya. На основе эфемерной рабочей нагрузки с доминированием записи было обнаружено, что для этого параметра лучше всего установить значение 3 секунды. По умолчанию установлено 30 секунд.

SAS Viya разделяет данные CAS на несколько небольших фрагментов, по несколько мегабайтов каждый. Вместо закрытия этих дескрипторов файлов после записи данных в каждый сегмент дескрипторы остаются открытыми, а буферы сопоставляются в памяти приложением. Без закрытия нет очистки до прохождения давления памяти или 30 секунд. Ожидание нехватки памяти и более длительное время ожидания показали свою неэффективность. В отличие от платформы SAS GRID, которая искала лучшую общую пропускную способность, платформа SAS Viya рассматривала оптимизацию пропускной способности записи.

`vm.dirty_writeback_centisecs`

Поток записи на диск в ядре отвечает за асинхронную запись "грязных" буферов между каждыми периодами ожидания потоков записи на диск. Этот параметр определяет период ожидания между записями на диск. Учитывая значение vm.dirty_expire_centisecs, равное 3 секундам, используемое SAS Viya, SAS задает для этого параметра 1 секунду, а не 5, как по умолчанию, чтобы найти оптимальную общую производительность.

Влияние ненастроенного кэша файловой системы

При рассмотрении конфигураций виртуальной памяти по умолчанию и объема ОЗУ в современных системах обратная запись потенциально замедляет другие операции, связанные с хранилищем, с точки зрения конкретного клиента, движущих эту смешанную рабочую нагрузку. Следующие симптомы можно ожидать от неуправляемого компьютера Linux с высокой нагрузкой на запись и кэша.

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

Это поведение проявляется только на компьютерах Linux, где выполняется смешанная рабочая нагрузка с интенсивными операциями записи. Кроме того, производительность снижается для всех томов NFS, подключенных к одной конечной точке хранилища. Если подключения поступают из двух или более конечных точек, это поведение проявляется только для томов, совместно использующих конечную точку.

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

Мониторинг виртуальной памяти

Чтобы понять, что происходит с виртуальной памятью и обратной записью, рассмотрите следующий фрагмент кода и выходные данные. Dirty представляет объем "грязной" памяти в системе, а Writeback представляет объем памяти, активно записываемой в хранилище.

# while true; do echo "###" ;date ; egrep "^Cached:|^Dirty:|^Writeback:|file" /proc/meminfo; sleep 5; done`

Следующие выходные данные поступают из эксперимента, в котором для соотношения vm.dirty_ratio и vm.dirty_background было задано 2 % и 1 % физической памяти соответственно. В этом случае запись на диск началась на 3,8 ГиБ, что составляет 1 % от памяти системы, равной 384 ГиБ. Обратная запись во многом напоминает пропускную способность записи в NFS.

Cons
Dirty:                                    1174836 kB
Writeback:                         4 kB
###
Dirty:                                    3319540 kB
Writeback:                         4 kB
###
Dirty:                                    3902916 kB        <-- Writes to stable storage begins here
Writeback:                         72232 kB   
###
Dirty:                                    3131480 kB
Writeback:                         1298772 kB

Поделиться через