связь dd с кешем страниц
На данный момент вывод свободных команд моего сервера выглядит следующим образом:
# free -m
total used free shared buffers cached
Mem: 995 780 205 0 49 599
-/+ buffers/cache: 140 854
Swap: 0 0 0
Мы знаем, что приложение dd обычно использует кеш страницы для ускорения доступа к файлам.
После выдачи команды команда:
dd if=/dev/zero of=2.txt bs=1M count=10
Следующий вывод показывает, что кеш страницы увеличился примерно на 10 МБ.
# free -m
total used free shared buffers cached
Mem: 995 790 215 0 49 599
-/+ buffers/cache: 140 854
Swap: 0 0
Предыдущий вывод нормальный.
Затем я выполнил команду
sync, которая синхронизирует содержимое в кэше страницы с жестким диском снова вместе с командой
free -m.
Ничего не изменилось. Связано ли это с механизмом обратной записи? который предусматривает, что кеш страницы не будет восстановлен, несмотря на выполнение команды синхронизации, если эта часть кеша страницы не будет изменена.
Или кеш страницы не будет переработан вообще до тех пор, пока не будет изменен параметр ядра / proc / sys / vm / drop_caches?
# free -m
total used free shared buffers cached
Mem: 995 790 205 0 49 599
-/+ buffers/cache: 140 854
Swap: 0 0 0
Если да, то какой максимальный размер может иметь кеш в 'free -m' достичь? Есть ли какие-то параметры ядра, управляющие этим? Спасибо.
dd не использует напрямую кеш страниц, он выполняет ввод-вывод, автоматически кэшируется.
Удаление кеша просто потому, что что-то было зафиксировано, неэффективно. Следующее чтение должно быть произведено с нижележащего устройства, которое, вероятно, в сотни или тысячи раз медленнее, чем RAM.
Ожидайте, что кеши будут использовать почти всю неиспользуемую RAM. Считайте, что это свободная память, кеши должны быть освобождены в первую очередь, если программы выделяют память.
Не используйте / proc / sys / vm / drop_caches в производственной операции, это не помогает. Из Documentation / sysctl / vm.txt
Этот файл не является средством управления ростом различных ядер. кеши (inodes, dentries, pagecache и т. д.). Эти объекты автоматически восстанавливается ядром, когда память требуется в другом месте в системе.
Использование этого файла может вызвать проблемы с производительностью. Поскольку он отбрасывает кэшированные объекты, это может потребовать значительных затрат ввода-вывода и ЦП для воссоздайте упавшие предметы, особенно если они интенсивно использовались. Из-за этого использование вне среды тестирования или отладки является не рекомендуется.
Документация sysctl для vm действительно перечисляет несколько параметров настройки для управления подсистемой виртуальной памяти, включая поведение грязных страниц и минимальное количество свободных. Я не рекомендую менять их, пока вы подробно не поймете преимущества этого. А пока используйте настройки по умолчанию или предварительно определенные настроенные профили.