Вопрос по usb, file-copying, caching, linux, filesystems – Как я могу ограничить кэш-память, используемую при копировании, чтобы оставалась память для другого кеша?

16

Basic situation:

Я копирую некоторые NTFS диски в openSuSE. Каждый 2TB. Когда я делаю это, система работает медленно.

My guesses:

Я считаю, что это, вероятно, из-за кеширования. Linux решает отказаться от полезного кеша (например, kde4 bloat, дисков виртуальных машин, двоичных файлов LibreOffice, двоичных файлов Thunderbird и т. Д.) И вместо этого заполнить всю доступную память (всего 24 ГБ) данными с копирующих дисков, которые будут прочитаны только один раз, затем написано и никогда не используется снова. Таким образом, каждый раз, когда я использую эти приложения (или kde4), диск должен быть снова считан, а чтение раздува с диска снова приводит к зависанию / сбоям.

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

Поскольку это USB, диск и контроллер диска не являются узким местом, поэтому использование ionice не делает его быстрее.

Я полагаю, что это кеш, а не просто материнская плата, которая работает слишком медленно, потому что, если я перестану копировать все, она все равно будет работать нестабильно, пока не получит все заново. И если я возобновлю копирование, пройдет еще минута, прежде чем оно снова станет прерывистым. Но также я могу ограничить его до 40 МБ / с, и он снова будет работать быстрее (не потому, что он правильно кэшировал, а потому, что шины материнской платы имеют большую дополнительную пропускную способность для системных дисков). Я могу полностью смириться с потерей производительности из-за того, что возможности ввода-вывода моей материнской платы полностью израсходованы (что составляет 100% использования, что означает 0% потерянной мощности, что делает меня счастливым), но я не могу согласиться с тем, что этот механизм кэширования работает так ужасно в этом конкретный вариант использования.

<code># free
             total       used       free     shared    buffers     cached
Mem:      24731556   24531876     199680          0    8834056   12998916
-/+ buffers/cache:    2698904   22032652
Swap:      4194300      24764    4169536
</code>

Я также попробовал то же самое на Ubuntu, что вызывает полное зависание системы. ;)

И чтобы уточнить, я не спрашиваю, как освободить память для «системы», но для «кэша». Я знаю, что кеш-память автоматически возвращается системе при необходимости, но моя проблема в том, что она не зарезервирована для кеширования определенных вещей.

Question:

Есть ли какой-нибудь способ сказать этим операциям копирования ограничить использование памяти, чтобы некоторые важные вещи оставались в кэше, и поэтому любые замедления являются результатом обычного использования диска и не перечитывают одни и те же часто используемые файлы? Например, есть ли настройка максимальной памяти для процесса / пользователя / файловой системы, разрешенной для использования в качестве кэша / буфера?

Ваш Ответ

7   ответов
1

dd вместо тогоcp .

Илиmount файловая система сsync флаг.

Я не совсем уверен, могут ли эти методы обойти своп, но, возможно, стоит попробовать.

Просто мой 2с.

По моему опыту, всегда полезно использовать rsync (без опции -u, которая разрушает все). Если нет, я получу необнаруженные частичные файлы, когда передача будет прервана. Peter
При первой попытке это не сработало с удаленной копией, поскольку сервер не поддерживает эту опцию. (оба имеют протокол rsync версии 3.0.9, версия 30; Linux поддерживает его, но FreeBSD 8.2 нет). И при локальных передачах скорость, по-видимому, несколько ограничена. Peter
@ Питер, я обычно стараюсь избегатьdd я забыл оrsync ... так много утилит: D KurzedMetal
Вставьте этот комментарий перед вторым комментарием ... как-то удалили: Спасибо за предложение. Это привело меня к чтению справочной страницы по rsync, в которой я нашел опцию «--drop-cache», которая на самом деле, кажется, хорошо работает для локальных передач. Peter
посмотрите на другой ответ, вы можете даже ускорить синхронизацию. KurzedMetal
3

но в моей ситуации я не хотел использовать dd или писать свое собственное программное обеспечение, поэтому решение состояло в том, чтобы использовать опцию «--drop-cache» в rsync.

Я использовал это много раз с момента создания этого вопроса, и, похоже, проблема полностью решена. Единственное исключение было, когда я использую rsync для копирования с компьютера с FreeBSD, который не поддерживает «--drop-cache». Поэтому я написал оболочку, чтобы заменить команду / usr / local / bin / rsync и удалить эту опцию, и теперь она тоже работает, копируя оттуда.

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

$ free
             total       used       free     shared    buffers     cached
Mem:      24731544   24531576     199968          0   15349680     850624
-/+ buffers/cache:    8331272   16400272
Swap:      4194300     602648    3591652
drop-cache не доступен в официальном rsync Krzysztof Krasoń
1

cp, но если вы хотите повторно внедрить или исправить это самостоятельно, настройтеposix_fadvise(fd, 0, 0, POSIX_FADV_NOREUSE) как для входного, так и для выходного файла, вероятно, поможет.

posix_fadvise() сообщает ядру о предполагаемой схеме доступа. В этом случае вы будете использовать данные только один раз, поэтому нет смысла их кэшировать. Ядро Linux соблюдает эти флаги, поэтому не следует больше кэшировать данные.

17

https: //github.com/Feh/nocach или найдите его в Debian и Ubuntu 13.10 (дерзкий).

Спасибо, Питер, за то, что предупредили нас о опции --drop-cache "в rsync. Но это было отвергнуто вверх по течению Bug 9560 - опция drop-cache), в пользу более общего решения для этого: новая команда "nocache", основанная на работе rsync с fadvise.

Вы просто добавляете «nocache» к любой команде, которую хотите. У этого также есть хорошие утилиты для описания и изменения состояния кэша файлов. Например. Вот эффекты с и без nocache:

$ ./cachestats ~/file.mp3
pages in cache: 154/1945 (7.9%)  [filesize=7776.2K, pagesize=4K]
$ ./nocache cp ~/file.mp3 /tmp
$ ./cachestats ~/file.mp3
pages in cache: 154/1945 (7.9%)  [filesize=7776.2K, pagesize=4K]\
$ cp ~/file.mp3 /tmp
$ ./cachestats ~/file.mp3
pages in cache: 1945/1945 (100.0%)  [filesize=7776.2K, pagesize=4K]

Надеюсь, что это сработает для других программ резервного копирования (rsnapshot, duplicity, rdiff-backup, amanda, s3sync, s3ql, tar и т. Д.) И других команд, которые вы не хотите разрушать кеш.

@ Peter Я думаю, что ответ nealmcb с 'nocache' более уместен, поскольку не все rsync имеют опцию drop-cache, а nocache используется более широко Krzysztof Krasoń
с моей точки зрения, каждый дистрибутив Linux, который я тестировал (кроме Manjaro, а также не FreeBSD), применял патч к rsync ... и nocache не было в openSUSE, когда я его использовал, и не входит в основные репозитории в арка / manjaro. И мне больше нравится идея nocache (так же, как мне нравится nice, ionice, trickle и т. Д.), Но если я не увижу ее в более крупных репозиториях, это своего рода субъективное решение, которое является лучшим решением для всех. Peter
@ У Питера Дебиана его нет Krzysztof Krasoń
@ krzyk В каком Debian нет nocache? Похоже на то, что это в wheezy-backports, Джесси, Стрейч и Сид: Packages.debian.org / с.и.д. / Utils / NoCache nealmcb
Я отвечал @Peter о --drop-cache в rsync Krzysztof Krasoń
1

Так как это USB [...]

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

Используйте более новое ядро Linux. У старых есть проблема с данными USB и «прозрачными огромными страницами». Посмотри этоLWN статья. Совсем недавно эта проблема была решена, см. «Управление памятью» в LinuxChanges.

Я использую openSuSE с ядром 3.1.0-1.2-desktop. Я не знаю, применимо ли это; Каковы симптомы этой конкретной проблемы? Peter
Интересно - но я не понимаю, как это выглядит. Мне кажется, что патч от Mel Gorman, обсуждаемый на LWN, отсутствует в текущем ядре (3.13-rc5), и я не могу сказать, где он был указан на странице LinuxChanges, на которую вы ссылаетесь. В каком разрешении и в каком ядре оно появилось? Благодарность nealmcb
1

что вы не будете использовать кэшированные данные при повторном копировании. Это ваше информационное преимущество.

Но вы можете установить swapiness на 0: sudo sysctl vm.swappiness = 0. Это заставит linux сбросить кеш до того, как библиотеки и т. Д. Будут записаны в сво

Работает хорошо для меня тоже, особенно очень производительно в сочетании с хью бараном (16-32 ГБ).

0

rsync и я мог бы еще копать:

Кажется, что rsync неэффективен при использовании с кучей файловв то же врем, есть запись в their FAQ, это не проблема linux / cache, это проблема rsync, потребляющая слишком много оперативной памяти.

Поглядывая вокруг кто-то рекомендовал разделить синхронизацию на несколькоrsync заклинания

Надеюсь, это поможет

Хорошая информация, но у меня нет проблем с памятью. У меня 22032652 байта бесплатно. Это может быть связано с тем, что большинство моих файлов имеют много ГБ. Когда запускается rsync, он говорит «18658 файлов для рассмотрения». Я также использовал его, когда у меня есть сотни миллионов файлов, и это тоже работает. Но благодаря вашему предложению dd и обнаружению этой опции --drop-cache она на самом деле кажется полностью решенной (пока я не делаю слишком много удаленных передач, когда сервер не поддерживает --drop-cache) . Peter

Похожие вопросы