Вопрос по usb, file-copying, caching, linux, filesystems – Как я могу ограничить кэш-память, используемую при копировании, чтобы оставалась память для другого кеша?
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:
Есть ли какой-нибудь способ сказать этим операциям копирования ограничить использование памяти, чтобы некоторые важные вещи оставались в кэше, и поэтому любые замедления являются результатом обычного использования диска и не перечитывают одни и те же часто используемые файлы? Например, есть ли настройка максимальной памяти для процесса / пользователя / файловой системы, разрешенной для использования в качестве кэша / буфера?
dd вместо тогоcp .
Илиmount файловая система сsync флаг.
Я не совсем уверен, могут ли эти методы обойти своп, но, возможно, стоит попробовать.
Просто мой 2с.
dd я забыл оrsync ... так много утилит: D
но в моей ситуации я не хотел использовать 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
cp, но если вы хотите повторно внедрить или исправить это самостоятельно, настройтеposix_fadvise(fd, 0, 0, POSIX_FADV_NOREUSE) как для входного, так и для выходного файла, вероятно, поможет.
posix_fadvise() сообщает ядру о предполагаемой схеме доступа. В этом случае вы будете использовать данные только один раз, поэтому нет смысла их кэшировать. Ядро Linux соблюдает эти флаги, поэтому не следует больше кэшировать данные.
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 и т. Д.) И других команд, которые вы не хотите разрушать кеш.
Так как это USB [...]
Замедление известная проблема управления памятью.
Используйте более новое ядро Linux. У старых есть проблема с данными USB и «прозрачными огромными страницами». Посмотри этоLWN статья. Совсем недавно эта проблема была решена, см. «Управление памятью» в LinuxChanges.
что вы не будете использовать кэшированные данные при повторном копировании. Это ваше информационное преимущество.
Но вы можете установить swapiness на 0: sudo sysctl vm.swappiness = 0. Это заставит linux сбросить кеш до того, как библиотеки и т. Д. Будут записаны в сво
Работает хорошо для меня тоже, особенно очень производительно в сочетании с хью бараном (16-32 ГБ).
rsync и я мог бы еще копать:
Кажется, что rsync неэффективен при использовании с кучей файловв то же врем, есть запись в their FAQ, это не проблема linux / cache, это проблема rsync, потребляющая слишком много оперативной памяти.
Поглядывая вокруг кто-то рекомендовал разделить синхронизацию на несколькоrsync заклинания
Надеюсь, это поможет
Похожие вопросы
