Linux отключить кэширование диска

ext4 отключить кэш диска

Имеется ли возможность отключения кэширования для раздела с файловой системой ext4 ? На нём расположены файлы БД, и кэш обеспечивается самой СУБД. Возникает ситуация, когда ненужный мне кэш ext4 занимает лишнюю память, провоцируя своппинг и общую потерю производительности.

CentOs 2.6.32-279.9.1.el6.x86_64 #1 SMP Tue Sep 25 21:43:11 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux СУБД Progress (OpenEdge)

На нём расположены файлы БД, и кэш обеспечивается самой СУБД

use raw devices, Luke

1. В ФС нет кэша по сути, есть page cache данных с диска, он независим от FS.

2. Выставь vm.swappiness=0 и кеш ни при каких условиях не будет вызывать своппинг т.к. будет очищаться при первом требовании.

В общем проблема надуманная.

1. В ФС нет кэша по сути, есть page cache данных с диска, он независим от FS.

значит я неверно диагностировал причину своппинга, но для СУБД я выделяю буфер 32 гига (из семидесяти), что-то же «отжирает остальное. » может быть как раз page cache

2. Выставь vm.swappiness=0 и кеш ни при каких условиях не будет вызывать
своппинг т.к. будет очищаться при первом требовании

выставлял 1-ку, попробую 0

Имеется ли возможность отключения кэширования для раздела с файловой системой ext4 ?

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

сейчас стоИт RAID из четырёх дисков SSD.

База лежит на раиде ssd, операционка на раиде SAS. Оперативки 72 гига, размер базы 460 гигов, клиентских подключений 600. Для буфера СУБД выделяю половину от оперативки. Все прекрасно работает, пока не появляется своп (расположен на SAS). Предположил, что причиной свопа явился кэш файловой системы. Иными словами цель — определить что занимает оставшуюся оперативку и прекратить своппинг. Нууу, и совсем шикарно было бы использовать под буфер СУБД не половину оперативы, а бОльшую ее часть.

Отключи своп вообще, если он тебе мешает.

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

Отлично себе поведёт, это же не винда.

Предположил, что причиной свопа явился кэш файловой системы.

Источник

Оптимизация Linux под нагрузку. Кэширование операций записи на диск.

Недавно на одном из виртуальных серверов столкнулся с проблемой долгой записи на диск. И под эту тему нашел интересную статью, в которой подробно рассмотрен вопрос функционирования кэширования операций записи на диск в Linux. Сегодня будет перевод этой статьи.

Кэширование в Linux

При записи данных на диск (любой программой) Linux кэширует эту информацию в области памяти, называемой Page Cache (страничный кэш). Информацию об этой области памяти можно посмотреть с помощью команд free, vmstat или top. Полную информацию об этой области памяти можно посмотреть в файле /proc/meminfo. Ниже приведен пример этой файла на сервере с 4-мя GB RAM:

Размер Page Cache показан в параметре «Cached», в данном примере он составляет 2,9 GB. При записи страниц в память размер параметра «Dirty» увеличивается. При начале непосредственно записи на диск будет увеличиваться параметр «Writeback» до тех пор, пока запись не закончится. Достаточно сложно увидеть параметр «Writeback» высоким, так как его значение увеличивается только во время опроса, когда операции ввода/вывода (I/O) поставлены в очередь, но еще не записаны на диск.
Linux обычно записывает данные из кэша на диск с помощью процесса pdflush. В любой момент в системе запущено от 2 до 8 потоков pdflush. В файле /proc/sys/vm/nr_pdflush_threads можно посмотреть сколько в данный момент активных потоков. Каждый раз все существующие потоки pdflush заняты по крайней мере 1 секунду. Новые потоки пытаются записать данные в свободные очереди устройств, таким образом, чтобы на каждое активное устройство был 1 поток сбрасывающий данные из кэша. Каждый раз по прошествии секунды без какой либо активности со стороны pdflush убирается 1 поток. В Linux можно настроить минимальное и максимальное количество pdflush потоков.

Настройка pdflush

Каждый поток pdflush контролируется несколькими параметрами в /proc/sys/vm:

• /proc/sys/vm/dirty_writeback_centisecs (default 500): в сотых долях секунд. Этот параметр означает как часто pdflush возобновляет работу для записи данных на диск. По умолчанию возобновляет работу 2 потока каждые 5 секунд.
  Возможно недокументированное поведение, которое пресекает попытки уменьшения dirty_writeback_centisecs для более агрессивного кэширования данных процессом pdflush. Например, в ранних версиях ядра 2.6 Linux в файле mm/page-writeback.c код включал логику, которая описывалась «если запись на диск длится дольше, чем параметр dirty_writeback_centisecs, тогда нужно поставить интервал в 1 секунду». Эта логика описана только в коде ядра, и ее функционирование зависит от версии ядра Linux. Так как это не очень хорошо, поэтому вы будете защищены от уменьшения этого параметра.
• /proc/sys/vm/dirty_expire_centiseconds (default 3000): в сотых долях секунд. Этот параметр указывает как долго данные могут находится в кэше, после чего должны быть записаны на диск. Значение по умолчанию очень долгое: 30 секунд. Это означает, что при нормальной работе до тех пор пока в кэш не запишется достаточно данных для вызова другого метода pdflush, Linux не будет записывать данные на диск, находящиеся в кэше менее 30 секунд.
• /proc/sys/vm/dirty_background_ratio (default 10): Максимальный процент оперативной памяти, который может быть заполнен страничным кэшем до записи данных на диск. Некоторые версии ядра Linux могут этот параметр устанавливать в 5%.

В большинстве документации этот параметр описывается как процент от общей оперативной памяти, но согласно исходным кодам ядра Linux это не так. Глядя на meminfo, параметр dirty_background_ratio расчитывается от величины MemFree + Cached — Mapped. Поэтому для нашей демонстрационной системы 10% составляет немного меньше, чем 250MB, но не 400MB.

Итого: Когда pdflush начинает запись?

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

• они дольше 30 секунд находятся в памяти;
• кэшированные страницы занимают более 10% рабочей памяти.

Если на сервере операции записи происходят часто, то однажды будет достигнут параметр dirty_background_ratio, и вы сможете увидеть, что вся запись на диск идет только через этот параметр не дожидаясь истечения параметра dirty_expire_centiseconds.

Процесс записи страниц

Параметр /proc/sys/vm/dirty_ratio (default 40): Максимальный процент общей оперативной памяти, который может быть выделен под страничный кэш, до того как pdflush будет писать данные на диск.

Примечание: Во время записи на диск все процессы блокируются на запись, не только тот который заполнил буфер на запись. Это может вызвать спровоцировать блокировку одним процессов всех операций вводы/вывода в системе. Провести этот

Рекомендации по оптимизации Linux для операций, требующий частой записи

Обычно люди при попытке увеличения производительности дисковой подсистемы сталкиваются с проблемой, что Linux буферизует слишком много информации сразу. Это особенно трудно для операций, требующий синхронизации файловой системы, использующих вызовы fsync. Если во время такого вызова в кэше много данных, то система может «подвиснуть» пока не закончится этот вызов.
Другая частая проблема происходит потому что слишком много требуется записать до того, как начнется запись на физический диск, операции ввода/вывода происходят чаще, чем при нормальной работе. Вы получите более долгие периоды, когда запись на диск не происходит, пока большой кэш не будет заполнен, после чего сработает один из триггеров pdflush и данные запишутся на максимальной скорости.

dirty_background_ratio: Основной инструмент настройки, обычно уменьшают этот параметр. Если ваша цель снизить количество данных, хранимое в кэше, так что данные будут писаться на диск постепенно, а не все сразу, то уменьшение этого параметра наиболее эффективный путь. Более приемлемо значение по умолчанию для систем имеющих много оперативной памяти и медленные диски.

dirty_ratio: Второй по значимости параметр для настройки. При значительном снижении этого параметра приложения, которые должны писать на диск, будут блокироваться все вместе.

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

Инструкция по настройке параметров

В файле /etc/sysctl.conf вносим, например:

После синхронизируем данные кэша и диска, очистим кэш и сохраним параметры.

Источник

Настройка ядра Linux для повышения производительности памяти

Контекст

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

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

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

Причина этого исключительно в том, что оперативная память используется на полную мощность, и других симптомов, кроме случайного эпизодического увеличения задержек, может и не быть. Такая же картина может наблюдаться, если жесткий диск не справляется с чтением и записью. Влияние может быть и на такие компоненты операционной системы как сетевая карта / iptables / ebtables / iproute2 — вместо реальной причины вы видите проблемы в сетевой задержке. В этой статье обсудим это подробнее и посмотрим, как минимизировать воздействие на систему.

Объяснение

В Linux есть несколько видов кэшей:

dirty cache — блоки данных, которые еще не записаны на диск (в файловых системах, поддерживающих кэширование, например, ext4). Этот кэш можно очистить командой sync. Очистка этого кэша может привести к снижению производительности. При обычном режиме работы не стоит этого делать, если только вам не нужно сбросить данные на жесткий диск, например, при аварии.

clean cache — блоки данных, которые для ускорения доступа находятся и на жестком диске и в памяти. Очистка clean cache может привести к снижению производительности, поскольку все данные будут считываться с диска.

inode cache — кэш информации о местоположении inode. Его можно очистить аналогично clean cache, но также с последующим снижением производительности.

slab cache — хранит объекты, выделенные приложениям с помощью malloc, таким образом, что в будущем они могут быть повторно выделены с уже заполненными данными объекта, что ускоряет выделение памяти.

С dirty cache мало что можно сделать, но другие типы кэшей можно очистить. Их очистка может привести к двум результатам. В приложениях, потребляющих много памяти, таких как Aerospike, задержки уменьшатся. Но с другой стороны, замедлится скорость ввода-вывода, так как все данные придется считывать с диска.

Очистка slab cache может привести к временному кратковременному снижению скорости. По этой причине очищать кэш не рекомендуется. Вместо этого, лучше сообщить системе, что определенный объем памяти всегда должен быть свободен и его нельзя занимать кэшем.

При необходимости очистку кэша можно выполнить следующим образом:

Большую часть памяти занимает page cache, поэтому если очищаете кэш, то рекомендуется очищать его (echo 1).

Для исправления проблемы можно установить минимальное количество свободной памяти. Рассмотрим следующий пример:

В этом примере свободно 10 ГБ памяти, ограниченной с использованием параметра minimum free . В случае, если потребуется выделить 5 ГБ памяти, то сделать это можно мгновенно. Для обеспечения 10 ГБ свободной памяти освобождается часть кэша. Выделение памяти будет происходить быстро, а кэш динамически уменьшаться, чтобы 10 ГБ всегда оставались свободными. Распределение памяти будет выглядеть следующим образом:

Точная настройка этих параметров зависит от вашей нагрузки. Для Aerospike, если это позволяет доступный объем памяти, должно быть не менее 1,1 ГБ свободной памяти в min_free_kbytes . Тогда кэш будет в достаточном объеме, оставляя место для размещения приложений.

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

NUMBER — количество килобайт, которые должны быть свободны в системе.

Чтобы на компьютере со 100 ГБ оставить 3% памяти незанятыми, выполните следующую команду:

Aerospike рекомендует оставлять не менее 1,1 ГБ в min_free_kbytes , т.е. 1153434.

В системе с общим объемом памяти более 37 ГБ следует оставлять не более 3% свободной памяти min_free_kbytes , чтобы ядро не тратило слишком много времени на ненужное восстановление памяти. В таких системах это будет составлять от 1,1 ГБ до 3% от общего объема оперативной памяти.

При установке этого параметра следует проявлять осторожность: слишком маленькое или слишком большое значение может отрицательно сказаться на производительности системы. Слишком низкое значение min_free_kbytes не позволит системе освободить память. Что может привести к зависанию системы или уничтожению процессов через OOM.

Слишком большое значение (5-10% от общей памяти) приведет к тому, что в системе быстро закончится память. Linux для кэширования данных файловой системы использует всю доступную оперативную память. Установка высокого значения min_free_kbytes может привести к тому, что система будет тратить слишком много времени на восстановление памяти.

RedHat рекомендует поддерживать min_free_kbytes на уровне 1-3% от объема памяти в системе. При этом Aerospike рекомендует оставлять не менее 1,1 ГБ, даже если это выше официально рекомендуемого значения.

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

Установите значение swappiness в 0 , чтобы уменьшить потенциальную задержку:

Примечания

ВАЖНО: Все изменения, указанные выше, НЕ сохраняются. Они действуют только во время работы машины. Чтобы изменения были постоянными, необходимо внести их в /etc/sysctl.conf .

Добавьте следующие строки:

Как всегда, будьте внимательны при редактировании подобных параметров. Проверьте их на тестовых серверах перед внесением изменений в продакшн-окружение.

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

Для проверки, что zone_reclaim отключен используйте следующую команду:

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

Источник