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

Статья
06/01/2023

В этой статье приведены рекомендации по кэшированию файловых систем для 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